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1- INTRODUCTION 

1.1 PAYMENT ROUTING AND INTRADA Y LIQUIDITY (FTS EURO TASK 5-10) 

Chase Treasury Solutions wants to be a major player in the new Euro curreny. To facilitate this Chase FFT FTS will be 
connected to a number of Euro clearing systems for extra flexibility in making payments. All other Chase branches will 
then use Chase FFT as their correspondent and send all IN currency payments through FFT FTS. 

Likewise all receipts for Chase branches will go from clearing to Chase FFT and Chase FFT will pass them on to the 
branches. 



Consequently FFT FTS needs to be enhanced to include a new payment routing process that will automatically decide on 
which Euro clearing channel a payment will take. 

Also, to be able to use these clearing channels most effectively Chase Treasury Solutions require a way of monitoring the 
liquidity within the channels. Furthermore they require FTS to withhold payments assigned to a particular channel when the 
liquidity in that channel has been lost - rather like an IDR system for liquidity. 



1.2 THE FTS EURO PROJECT 



The Euro analysis work undertaken by the FTS systems group has been based around the Chase Treasury Solutions 
umbrella plan prepared by Nigel Knight. Within the plan a number of task were identified for analysis by Product 
Management, Payment Operations and Systems. 

* ! si The Functional Specifications have been produced to correspond to those tasks on the Umbrella Plan where systems 
changes were necessary within the FTS system, and other systems which the Chase Treasury Solutions Systems group 
j y support (e.g. CHAMPS). Payment Routing and Intraday Liquidity (5- 10) is one of these tasks. 

jj j Likewise SDIPs are being produced for each of the umbrella tasks (except where some tasks have been combined into one). 

1.3* THIS DOCUMENT 

j U This document is the Systems Design and Implementation plan for this part of the Euro project. It describes the design of 

the proposed Enhancements to FTS that will deliver the requirements laid out in the functional specification that was issued 
ui on 31/10/97. The content of this SDIP (and all FTS Euro SDIPs) is slightly different from previous FTS SDIPs as follows: - 

C3 1) Due to the very tight timescales and immovable deadlines for the overall Euro project, it was agreed that Section 3.0 
Existing System Description would not be completed as vigourously as in the past. The only areas of FTS that will 
appear in this section now will be those that are not sufficiently documented already, and that required further 
investigating before changes could be designed. 

2) For the Euro project Function Specs were produced detailing the user requirements. There is no point repeating these in 
section 4.0 Requirements. Instead section 4.0 just contains any changes or additions to the Function spec requirements. 

The main functions of the SDIP have then changed slightly and are now as follows :- 

• To ensure the system design is technically feasible, and will meet the users requirements. 
, • To ensure the project will meet the requirements, service level, and scope agreed in the Functional spec. 

Ideally, following implementation, this document should be combined with the existing FTS SDS's to keep FTS 
documentation up to date. 
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2. MANAGEMENT SUM 




2,1 PROJECT SCOPE 

This document has considered Chase Euro requirements only. Requirements and changes for JP Morgan (important as they 
may want to be a Euro Clearing branch) are not covered as so far there has been no input.(NB There is a separate Euro Task 
fox Outsourcing). However, the design proposed (for Chase) in this document is multibranched and so is capable of being 
used by other (outsourced) banks. To switch it on for other banks will just require static data changes. 

All processing that relates to the details of how clearing channels will work are excluded from the scope of this SDIP There 
are separate SDEPs for changes required for each clearing system. For example, the following are related to this SDIP but 
not included:- 

Receipts of MT0l2s 
Returns 

Formating of clearing messages 

Validation (in payment routing) of transactions destined for a particular channel. 



2.2 CURRENT PROCESSING 

Currently DEM clearing in Germany is the only IN country clearing that Chase FFT is connected to. Through FFT FTS 
Chase can send EAF and ELS DEM clearing payments. As there is only one clearing to manage in FFT, FFT branch can 
^_ monitor its liquidity manually using the ABK platform. 

™j Hence in FTS currently, the decision on which clearing mechanism to use does not arise. The clearing is dependent on the 
r- currency being cleared. That is, if the payment is DEM then Chase has to go through the Germany clearing via Chase FFT 
r- branch. If the payment is Sterling then Chase has to go via Chase UK and Midland to the Sterling clearing in London. 

2M CURRENT PROBLEMS 

I"" This project will not be addressing any current problems. Instead it aims to make Euro payments processing in FTS as 
^ flexible as possible to give Chase a competitive edge. It also aims to prevent potential problems that might occur with the 
introduction of the Euro on 1/1/99. 

rj 

2.3A New Clearing channels 

The Euro strategy for Chase requires that FFT branch becomes Chase's Euro correspondent All Chase's Euro payments 
will go through FFT branch. Also, FFT branch will have to be connected to the French clearing system , the EBA 
clearing system, and the Chaps Euro clearing system. Other FTS Euro projects are addressing the requirements for 
connecting FTS to these clearing systems. 

This project will provide Chase FFT with an automatic process that will decide which of these clearing channels is the 
most appropriate for a Euro payment. 

2.3.2 Liquidity imbalances 

Releasing a large amount of payments down any particular Euro clearing system may cause an imbalance in the clearing 
systems such that our payments are not made. This will depend on which channel the other banks use to send credits to 
FFT. Chase FFT will need to maintain the equilibrium of payment flows in each channel such that we only send 
payments to clearing systems where we have sufficient liquidity at that time. 

If the liquidity in a a particular channel is used up, FFT will need to be able to recognise this and route payments down a 
different channel. 

Also, it is anticipated that a confused situation will exist in the fust few weeks and months of Euro in terms of who is 
using which payment channels , and what their performance is likely to be. 



IJl 
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2.4 ALTERNATIVE CONSIDERED. 

No alternative overall design co^^vas considered (apart from doing nothing). The p^BPafTects many areas of FTS 
and alternative ways of enhancing each of these were considered. However, these were technical options that are discussed 
elsewhere in this document, and it would be inappropriate to repeat them here. 

2.5 PROPOSED SYSTEM 



2.5.1 New clearing systems 

For ultimate flexibility when making payments FFT branch will be connected to the following EURO clearings 

NET: SNP RTGS : TBF TARGET is a special RTGS channe l that fa n^l ro 

EBA Chaps Euro connect from one RTGS channel to anoth er 

EAF ELS RTGS channel. 

Also, if we need to use a clearing that FFT is not connected to, our correspondent banks can be used. 



2.5.2 Initial Message Processing. 

Initial message processing for FFT will be changed such that it can receive in the customers preferred clearing channel. 
This information will be held in tag 72 of the inconuning message. These details will be identified and a new field on 

^ FT-TRANS populated. 

1*3 

2.5[3 Straight Through processing and Payment Input 

ni 

j j j Within straight through processing, new validation will be included to cater for the channel specific details that may be 

1 1 j input. No validation will be performed on these details at NON-FFT branches. The details will be passed on to FFT in 

i.s. TAG72. 
. — 

|^ Validation will be performed in FFT to ensure that the channel details are valid. If not changes will be made so as to limit 

I the need to send to repair. 



2 " uj* Risk Contro1 (* DR )> CLC, and Marketing Approval functions 

Hi 

EURO payments need to be routed to the new Payment Routing module while all NON-EURO payments will need to be 
sent straight to Product Gen and not to go through the routing module. 



2.5.5 Payment routing 

For the bulk of Euro transactions going through FFT FTS the clearing channel they go through will be chosen by a new 
Payment Routing background task. This process will decide which clearing to use based on a number of factors. 

The Routing process will be placed in the FTS Payments flow after IDR and before Product generation (see diagram in 
Appendix A). It has to go before Product generation as this is where the specific formatting for the different channels is 
done. It is placed after IDR to ensure that as much validation and general formatting is done on the transaction prior to the 
routing module. 

Payment routing will pick up all clearing transactions. For transactions with payment type of CLG it will try and decide 
an appropriate route. Transactions with payment route set to a proper value (EAF, ELS, SNP etc. ) already will be read by 
the routing module but the logic within it that decides on payment routes will be bypassed. 

For every transaction read the Routing module will add a record to the new flow control database file (FT-FLOW- 
TRANS) so that the transaction is included in the Flow Control checking process. 



0M W Mhf:C11*MTCW3i7f»'WMa2t?DOC 
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2*5.6 Flow Control 

• A 

Two new background tasks will^^ovided for the flow control process. These will chc&Hm balance for the Clearing 
member within the channel, and the balance for the Channel as a whole. Depending on whether the balances exceed set 
limits it will either hold the payment or release the payment to Production Generation. 

Payments that are held because the balances have exceeded the set limits will be accessable to Ops by a new online 
system. By using this online system OPS will be able to :- 

a) Select one of the clearing queues to display ail the held payments 

b) Manually release any of the queued payments (down the channel) if required 

c) Manually put a payment back to the payment router (so a different channel can be selected) 

Rerouting back to routing module or releasing a payment from a queue will cause the bilateral & channel totals to be 
updated automatically. 



2.5.7 Payment Type flow 

Payments with payment type requested 

The proposed system will allow the customers to request a specific Euro clearing mechanism to be used for their Euro 
payment If this is specified the system will try to honour it but this is not guaranteed. Within payment input and straight 
throughs validation will be performed to ensure the necessary data for that channel is held on the transaction. 

These payments will go into Payment Routing but purely to add records into the Flow Control processing. No actual 
Q muting processing will be required as the route is already decided. Liquidity payments will be identified by having a new 
l = T instruction type of "LQ". 

|i j Payments with CLG payment type 

L5 If a clearin 8 mechanism has not been requested the initial stages of FTS will set the payment type to a value of CLG 

j ; j (stands for clearing). The payment Router will then decide on the most appropriate channel. 

; For these Payment Input and Straight Throughs will ensure that there is at least one channel that FFT can use to get a 

},:& P avTnent to . ^ Clearing Member specified. Because we dont know at this stage which channel will be chosen by the 

jl" Router, validation will ensure that the necessary transaction data is available for every channel that can be used for this 

) l * cl earing member. 

« j Payments destined for a correspondent 

jjM Payments destined for a correspondent rather than a clearing that FFT is connected to will have payment type of CLG. 

\U Specific channel validation will not be done on these payments. 

These will still be picked up by payment routing and the payment type will be set to CPO. They will need to go through 
Flow Control as we need to maintain balances for our Correspondent relationships. 

CPOs 

Any Euro transaction that has a payment type of CPO will not be a clearing item. Hence they wont go through Payment 
routing or Flow Control (e.g. Credits down the payments leg). 



2.5.8 Accounting 



All EURO clearing payments will be posted to a wash account in Payment Input, Straight Throughs and Payment Routing 
and will be posted to the correct NOSTRO account once the ACK has been received from the clearing that was ultimately 
used to transfer the funds 
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2.5.9 Contingency 

A contingency function will be provided to capture payments that have either been rejected at the clearing bank or errored 
at some stage of the payment flow out to the clearing bank, to enable them to be sent back to Payment Input or back to the 
Payment Router. 

This functionality currently exists within FTS for DM clearing and so it will be amended to work for all Euro clearings.. 



2.6 BUSINESS BENEFITS 

2.6.1 Payment Routing 

The Payment Routing function will allow FTS to make the most efficient use of the various Euro clearing systems that 
FFT will be connected to. It will allow Operations to ensure Payments are send by the most cost effective or quickest route 
to the beneficiary. 

If one Clearing system was to crash, it will be posible, via the Payment routing function, to stop payments from going to 
this channel and instead route to another channel. This should save Operations time and effort trying to recall payments. 

2.6.2 Payment Flow Control 

m Because Euro can be cleared by more than one clearing system it is likely that Chase will get imbalances in the flow of 

^ payments against credits in these systems. This will result Chase having large credit balances in some clearing systems 

; J : and large debits in others. 

p i If FTS was to continue sending payments out to a clearing that had a large debit balance, the payments may get blocked 
; by the clearing. This would interfere with Chase's ability to make payments quickly and efficiently. The proposed Flow 
Control system will allow Operations to monitor the positions in the clearing systems and prevent payments from bein« 

Wrf blocked. & 



2&\ IMPLEMENTATION PLAN 



This project will follow Chase Treasury Services project plan fro all of the Euro.- 



i5*i 



Phase 


Start Date 


End Date 


Systems Design 


01/10/97 


31/12/97 


Coding/Unit Testing 


01/01/98 


31/03/98 


Systems Testing 


01/04/98 


31/05/98 


User Acceptance Testing 

(including testing with other systems/LOBs) 


01/06/98 


31/08/98 


Implement Code to Production 


01/09/98 


30/10/98 



There is a more detailed plan of all Chase Treasury Solutions Euro projects that has been published separately. 



I fmf: CAmNOOW9lTB**-G0*ia7 DOC 
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2.8 ASSUMPTIONS/GLOSSJ^^)EPENDENCIES/OUTSTANDING /S, 

2.8.1 ASSUMPTIONS 



1. The router will assume that all payment details for the various clearing channels are available at the time the decision 
of which channel to use is taken. It is up to the individual FTS EURO tasks for the various clearings to ensure that all 
the required details are captured/available when the product generation is reached, i.e.: When an 'IN'/EURO payment 
is to be made, the router need not be concerned whether all the necessary details are available or not. 

2. All 'IN7EURO currency payments at the various FTS branches will be sent to FFT for clearing. 

3. All receipts for Chase Branches will go from clearing to FFT. FFT will then pass them on to the required Chase 
branch. 

4. Process for holding and updating which clearing a correspondent is attached to is to be handled by FTS EURO tasks 
for the individual clearing channels. 

5. Chase will be notified in advance of any change in the clearing bank members (either new members or ones that are 
no longer members). As the table info/processing does not have any date processing included, these details will need 
to be added on the day the bank becomes a member of the clearer. 



2.8.2 DEPENDENCIES 

Q 1 . This Euro sub project is dependent on FFT being successfully connected to the required clearing systems (EBA, 
j»* Chaps Euro, French) by 1/1/99. The work for these connections is being done under separate Euro sub projects. 

! ; j 2. The timely completion of the build phase of this project is dependent on 6 programmers being available full time for 
Ij J the 3 months January, February, and March. 

i t 

f= = 

2.8.3 OUTSTANDING ISSUES 

I j 1 . When the Euro messages arc acknowledged FT58 will back out the credit to the wash account, and credit the nostro 
I-= account actually used. Should we blott the new nostro account and reverse out the wash account blotting? 

y i 

M j 2. In the online flow control screens, for EAF and ELS channels should we display the BLZ code or the SWIFT address 
(if there is one)? If there is no swift address then we will have to display the BLZ code. For all the other channels 
Swift address will be displayed. 

3 . Cut-off time processing requirements 

4. Processing requirements when link to a clearing is down but the clearing is available. 

2.9 APPROVAL RESPONSIBILITIES 

Accountable Executive: Steve Round 

Third Party Review: Matthew Lynch 

GPTS Product Management: Nigel Knight 

Business Manager: Michael Canon 

Operations Manager: Les Green 



Version 1.0 - Page: 11 



2.10 GLOSSARY 

j ' 
There are some new terms used in this document that need explaining, as follows. 

Clearing-Member - This is the bank that is on the other side of the clearing. Also known as the "Paybank" for Non-X- 
Border payments and 'Their Correspondent" for X-Border payments. This is the bank that we hold bilateral agreements 
with. This SDIP refers to this entity frequently and using the terms Paybank or Their Corresponent was found to be 
misleading and unwieldy. Hence the term Clearing Member is used instead. 

Liquidity payments - These are payments used for changing the liquidity in a channel to remove a block. For instance if 
Chase is long in TBF and Short in CHE then a payment could be processed to move money from TBF to CHE. These 
payments can only be input by FFT Operations. 
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3. EXISTING 'SYSTEM 



SveTe 0 ^ ,a rf!ll mO T. 0fW0rk inVOlVed f ° r Eur ° aDd * e sh °" *«* «nlv certain areas on the existine system 

have been described here. Most of FTS is described sufficiently in existing documentation. However there are so™ a 



3.1 PRODUCT GENERATION 

^ project requires significant changes to the current Product Generation and Acknowledgement process Conseauentlv 

Notes on product gen processing relevant to this project:- 
Product generation has two reads of FT-TRANS. 

SS£! ^rSS^'SSr StatUS ValUCS ^ 10 ^ ^ ° n BGD reCOrd ™ cse « ""uses * 
fc ^3^1 if loi are re 8 quir °d P *"* tranSaCtt ° nS ™ PUt ,0 375 °° 2 if D ° m °' e P roduc * ™ or 

•« rfFoT^i^T^ a " ^ ^x 500,S - F ° r SCC ° nd read ^ 375001 '«° rds cou, d be ^d by any of the clones 
„ . of F08. The distinction between DM clearing products at 375001 or Chaps clearing products at 3750o7or anv 2 
U cleanng products is made after the read by checking the Payment Type. P roauc » * '5001, or any other 

Items that can go to 376 :- 

I l) ^s^ x 5^^sssr and for any c,earin8 * at camot hand,e forward va,ued 

pas 

; ^o^e'wh^^ 6 f T? d Va !!?u • H ° WeVer ' WhCn CbK ^ doses heW ° n ^le CHP - mis is not the Sterling cut 

51 SS^SJx"^ Ch3PS tranSaCti ° nS Pr ° CeSSeS 3fter *" *« DCCd * be b6ld tomorrt ^£2 J 



'13 



DEM and French clearing items are not processed after the clearing cut off so no problem with them. 
3.2* OVERVIEW OF DM CLEARING CONTINGENCY 

M^yTTfZ b f C n VailaWe 31 ° M » ™ st tave failed at some stage in its flow to the clearing 

Payments at any one of the following stages can be accessed by the contingency function for reprocessing. 

L A iH^fS5tS 1^ m \ ' ™^ ^ ,OCal where on one day an MT100 is sent 

^^^^^^ 

f;^' ? I! dUCt Deli u e,y AWaiting Acknow ««teemenU. - The message has been generated and sent to MHS but no 
^^^^ 

t ftol^enSor 0 ' ^ " ™ S " ^ " ^ Wi * ^ and the "e generated 

MHS and rnarks^nt Son as rjectl * ka0 * M * em « «* picks up the status update that is sent back to 
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In order to process the payment^fce above statuses a screen is provided and from th n there are three options: 

1. Route all rejected payments t^Hyment Input. 

This is where payments that have been rejected by LZB are routed back to Payment Input for reprocessing. 

2. Route an individual payment that has been rejected back to Payment Input. 

A FTS transaction reference must be input for this option and it has to have been rejected by LZB. This is routed back 
to Payment Input for reprocessing. 

3. Route other completed payments back to Payment Input. 

A FTS transaction reference must be input for this option and it must be at a certain status i.e. Cannot be processed by 
MHS or Product Delivery Error. These two statuses occur in Product Generation. This will be routed back to Payment 
Input for reprocessing. 



3.2.1 CURRENT CHAPS CONTINGENCY 

The CHAPS Contingency Print function allows payments at Product Delivery that are either waiting to be sent, waiting for 
acknowledgements or there has been an error with the payment to be contingency printed. This moves the payment on to 
Awaiting accounting' status. The message for the payment can be retreived by Merva and manually recreated and sent out 
again with a different Tag 20 transaction reference. 



3.2,2 CURRENT SWIFT CONTINGENCY 

C3 

|^ The SWIFT Contingency print function is similar to CHAPS in that it allows a message to be manually printed and the 

l k payment moves on to 'awaiting accounting' status, but it covers a wider range of payments to be picked up. Payments at 

j=l { the following statuses can be SWIFT Contingency printed: 

1 . At Product Delivery products to be sent. 
; : r f 2. At Product Delivery awaiting acknowledgements. 

3. At Product Delivery error. 

4. DM Product Delivery error. 

I** 5. SwifVTelex at Product Generation. 

\ l j 6. Swift/Telex awaiting acknowledgements. 

H fe 7, Swift/Telex at Product Generation error. 

if? Current Processing for contingency will remain. But the DM Clearing Contingency will be enhanced to 

w3 include CHAPS euro payments and French euro payments. 



3.3 STRAIGHT THROUGH PROCESSING 



The straight through program FTK0014 calls various modules which can be catagorised as follows:- 
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1 

FTK0014 r* 



Completion 
modules 



Blotter validation 



Transaction 
validation 



Document 
printing 



-> Routing 







thzscrtntion 


Decision on when to call : >. : S " „ . 'i J: 




FTK0015 


TRANS COMPLETION -DIRECT PYMT 


SOURCE-SYSTEM = 'K' 




FTK00I6 


BLOTTER VALIDATION 


After valid return from completion module 


n i 


FTK0017 


TRANS VALIDATION 


AH code. Validation of payment types so will need to 
include *CLG* as a valid payment type. 


• : ! 


FTK0019 


DRAWDOWN IAT COMPLETION - 


SOURCE-SYSTEM = 'G' <and> 


\ ; | 




CCAP 


MESS-TYPE = '21 T <and> 








BRANCH = '671* 




FTK0022 


TRANS COMPLETION - TSL1P/RPI 


SOURCE- SYSTEM « T 




FTK0023 


ROUTING MODULE 


The last module all transactions go throught 


ilJ 


FTK0024 


DOCUMENT PRINTING 






FTK0026 


TRANS COMPLETION - UK CCAP 


SOURCE-SYSTEM = *G' <and> 








MESS-TYPE o '21 1" <and> BRANCH -'671* 




FTK0027 


TRANS COMPLETION - UK 


SOURCE-SYSTEM = 'R* <and> 






STERLING SWIFT 


BRANCH = '671' <and> 
DB-CURR-CODE = WO 5 - ATB AS-CURR 




FTK0029 


TRANS COMPLETION 
(FOREIGN CURRENCY SWIFT) 


SOURCE-SYSTEM = 'R' <and> 
DB-CURR-CODE o W05- ATB AS-CURR 




FTK0032 


TRANS COMPLETION -NON UK 
LOCAL CURRENCY SWIFT 


SOURCE-SYSTEM = *K <and> 
BRANCH o *671 , <and> 
DB-CURR-CODE - W05-ATBAS-CURR 




FTK0033 


TRANS COMPLETION - NON UK 
LOCAL CURRENCY CCAP 


( SOURCE-SYSTEM - 'G* <and> 

MESS-TYPE o '2 1 V <and> BRANCH o '671' ) 

<or> (SOURCE-SYSTEM = T) 




FTK0036 


TRANS COMPLETION - 


SOURCE-SYSTEM = Q' 






DM CLEARING 




FTK0037 


TRANS COMPLETION - 
SIT CLEARING 


SOURCE-SYSTEM = 'Q' <and> 

BRANCH = '609' <and> W01-TAG20-SIT « TP' 




FTK0075 


PAYMENT RESTRICTION RULES 
CHECKING 


All transactiosn go through this. For OFAC checking. 



■ JUT; C M WMOOWgTE*^ 9 0 01 97 OOC 
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FUNCTIONAL REQUI^/IENTS ~* ; 

The main requirements were described in the Functional spec previously issued. This section documents any additions or 
changes to those requrements documented. 

1 CHANGES TO FUNCTIONAL SPEC REQUIREMENTS 

The numbers below relate to the paragraph numbers in the Functional spec. 
33.1 ChapsEuro returns 

The users now suggest that this will be manual. Furthermore, it is outside the scope of 5-10. 
3.4 Customer specification of payment route 

The payment route specified by the customer using /RTGS/ELS etc is now the DESTINATION clearing rather than the 
input clearing. This is because the Input clearing only affects Chase's liquidity. The Destination channel affects the 
customers Liquidity. E.G. if RTGS/ELS is specified Chase could pay thru CHE, and Target, to ELS, and hence to the 
correspondent bank. 

This then allows for clearings to be specified that are not clearings that Chase FFT is connected to. Like in the portuguese 
example /RTGS/PTE would go Straight Through as these other clearings would be set up on a new validation table. 

V\ 3.5 Ops specification of payment route 

!j The NB2 should be removed and note that - It must be ensured that FT-TRANS fields are populated consistently whatever 
the input mechanism. 

jj 

j i 3.8 Automatic Liquidity checks 

* j Neither Ops nor Credit control (Joff Henley) require the Aggregate Bilat checking process and so this has been removed 
from the project. 

, ; , 3.8.3 (and 3.8.1) Checking of positions by FTS 

The maximum payment amount check mentioned for all the levels of checking is actually only required at the Debit Cap 
, s . level. The maximum amount is required to be held in static data as an amount rather than a percentage. 

f J The order in which payments are required to be checked has changed. The idea of processing oldest payments first has been 
dropped. Also the idea of processing held payments first. It was felt that these requirements were of no benefit. 
Instead smallest amounts need to be processed first, and the urgent first. 

3*8.4 Rerouting of payments 

Note that when manually rerouting the user must consider the same factors that the Routing module considers (is the new 
channel on holiday? Is their correspondent connected to it? Etc). 

3.8.7 Rerouting of payments 

Add d) for selection to reroute (with validation) to a specific channel (as per last but one para of 3.8.4). 
3.11 Removal of queues 

Note that, due to steps that might be taken to fund a clearing account, the actual balance in the clearing may be different to 
the maintained balance in FTS Flow Control totals. This will be compensated for by Ops changing the Flow Control limits. 
A function to adjust the balances is not required. 
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4.2 ADDITIONAL REQUIREMi 



,4,2.1 Correspondent banking Flow Control 

It is required that payments sent out of FFT to correspondent banks (when there is no link to the paybank via EBA etc) 
must be controlled in the same manner as other Euro payments(IE by the Flow control process). 

To Chase FFT, correspondent banks are just another payment channel. The Bilat is still with the Paybank. Hence limits 
will be held for the clearing member through that Correspondent, and for that Correspondent regardless of which clearing 
member. The actual clearing that the correspondent puts the payment through is irrelevant to the flow control process. 

If ops do not require these payments to be held they can just set the limits to ridiculously high values. 



4.2.2 Correspondent banking Credits 

It is hoped that the Credits coming back from these ultimate beneficiaries/paybanks will go direct from clearing to Chase 
FFT. Our remittance instructions will ask for this. However, some banks may not like this (especially if target is 
expensive) and so may send the credits through our correspondent. There is no requirement to add these latter credits to 
the Flow control balances. Ops will advise these banks to pay the credits as per the remittance instructions next time. 



4.2.3 Customers specifying clearing channel requirements. 

No validation will be included to check whether the customer is allowed to specify channel specific information or not. 
i.e.: Anyone can use the facility. The control will be that the facility will not be actively marketed to everyone. The reason 
for not validating this data is that OPS do not wish to unduly affect the straight through processing. 

4.45* Target payments 

{i j When we send payments via target to a clearing member, Flow Control must update the balances for the first RTGS and 

\j j the clearing member. We will not maintain a balance for the destination RTGS. 

I.-J 

1-4 When FTS deliberately sends a payment via target (like the portuguese example in the Functional spec) FTS should 

v maintain our bilat balance with the Portuguese clearing member. If we dont have a bilat relationship with the Portuguese 

l sh clearing member the Flow Controller looks for it on FT-FLOW- CONTROL and if not found it follows the procedure 

j*. | below under the title "if limit records are not found by 'Automatic Bilat controller". 

4.2$ Streaming of Flow control 

m It is felt that there could be a need to stop the Automatic Flow Controllers from processing a particular channel. But this 
does depend on what Ops procedures are finally agreed. Given this possibility, and the fact that whatever is agreed now 
could change on 4/1/99, and the possibility of big volumes, it was agreed that the flexibility provided by su-eaming would 
be a good idea. 

This streaming will be by branch i.e 616 and 190. Within this 616 will be streamed by Clearing group as defined on a new 
table 4 CLG\ Users do not want to be able to single out payments made on behalf of a particular Chase branch. 



4.2.6 Online Flow control options 

In the Func spec the options available in the Flow control online screens depended on the type of payment eg Ops 
liquidity payments could not be rerouted. 

However, it has now been agreed that to cut development costs these distinctions would be dropped. Instead all options 
will be available for all payments regardless. 



4.2.7 Queue Status enquiry 

The queues/catagories displayed in FTS Queue Status enquiry will be changed for 616 branch to include the Payment 
routing and Flow Control status's. 
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4.2.8 Updates to the CAR 

There is no requirement to sho^^ment routing or Flow Control statuses on the Ci ^^ 

4.2.9 Reset balances to zero overnight 

^ltZn?Ztl°£* nCCeSSari,y bC 2er °- H ° WeVer ' ^ F,OW M bal — ~* «« reflect this and 

4.2.10 Flow control for RTGS systems 

The basic requirement is that:- 

Most bifa^RTr^'T 1 T"™ Wil !. need t0 bC ChCCked and C0Wr0 » ed at bi,at level - P«vio«.ly agreed 
Most b lats m RTGS systems do not need to be controlled at all at bilat level. However, if a problem arises with a 

L~ sarv of " Tit "rr"" SOing 10 *" bank « RTCS can be con^olledtf 5 s ded?e!t is 

& BuZss^r" ^ " ^ adV,SCd ° f 3 Pr ° bIem - ^ WOUW be * uided * Treasu^SoluW Credit 

To meet these requirements the following was agreed :- 

^ R- w B h ilat C PCrf0nnS * e limit CheCk °" 3 P 3 ™ 1 wi " be 8^=d by a new flag This flag will be 

to^^^^^t do for *" bilat/chaMci is ^ baiance < for ^ - d ~ ™* 



:1 s 



In most cases bilats within RTGSs will not need controlling and so this flag will be set to N for them Bilats in Nets 
will need controlling and so Ops will set the flags to Y for those 
UJ (the system will auto set the record based on the record set on the Channel Control table NS & Correspondent 

hJ channels are controlled, RTGS are NOT.) correspondent 

4 -?^l If limit records are not found by the system 

^ h?rfTlS bC ( , eSpedall y Ja " /Feb 19 ") when ^ payment is processed for a bilat/channel combination that hasnt 

« new^irZn * • up ye ;- j or *r ~? * e Au,omaric Biiat contro,ier set a iimit — rd 

£ S T , rCCOrd WlU depeDd ° n 1116 default for 1116 chann *> (indicated by a flag on the chaleSc 

J ^ f'T"^ uuTl 15 3 COntr ° lled Channel (USUal 'y Nets ) * wi " s « the flag for «4 bita^tSS Yes 

Tins default semng will be held against each channel on the table that holds channel iL (ECC table" 

Hence if the default for the channel is Yes (NS or Corr)the bilat controller will -- 
set the Bilat'channel flag to Yes on the new limit record 

set the limit on the new record to -999,999,999,999,999,999.99 (so that further payments get held) 
put this payment to the hold queue e ' 

If the default for the channel is No (RTGS) the bilat controller will •- 

set the Bilat/channel flag to No on the new limit record (so that future payments dont get controlled) 
set the limit on the new record to zero 
release this payment tothe Debit cap controller 



fia,?^™? f °i 3 bUat/channd mat doesnt hav * • limit record then one will get automatically set up The limits and 
Hags will be set in the same way and with the same considerations as above. 

A report of these may be required but this is to be the subject of MIS discussions later on. 
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4.2.12 Product Generation - ABKpayments made with Telegraphically indicator. 

Currently payments over 300,cAl - Ops look for information in TAG72 where th Jfcner has requested the 
TXTka* 7 LE G|^ CALLY> *is is a means of prioritising the pavrlKL they ha^ve t en t n , to 
^rv"k t!t m f ° U " d * Bouraem ° uth °P S P^ne FFT Ops who then flag the payment as an ELS tele graphic on 
the ABK box. No system changes will be required for this process. '^grapmcon 

4.2.13 Clearing channel data on direct and reimbursment. 

No channel specific details (/NET/ or /RTGS/) will be sent out on the outgoing messages from FFT. 

For NON-FFT branches that need to send a Direct with reimbursement instruction: Only the reimbursement instruction* 
sent to FFT (EURO payments) will have the channel specific details mapped to TAG72 CUnDurSement ^truchons 

"SZSZS^xxx^z Direct onIy: nc Direct messase sent to fft (euro paymen *> wi » «- 

4.2.14 New instruction type for Liquidity Payments 

A new Instruction type for the liquidity payments will be made available to FFT payment input. New code = 'LQ'. 

4.^.15 Processing NOT performed by the Payment Router. 

p • Customers ;may want FX to go through EBA but other payments through a different channel, and they will not want 
M to set this m TAG72 on every transaction. No changes will be made for this request to FTS. Use Swift TTDS' 

W " f™* ' SS1 ( Dat f base - As this facility was not going to be available till the 1st or 2nd quarter of 1998, the inclusion of 
fj j this request in the current EURO project was not possible. inclusion oi 

| . i 

^ ' Ul^Z l^t'Vu ,Min,a i D * hiSt0ry ° f Channek M 1116 reaSOn for "formation was mat if a customer had 
requested ELS but because of certain factors (e.g.: ELS had crashed), we had to use TBF to affect the payment we" 

U 7 Uld n " d t0 ha ^ e som l mdicati ° n *at we had tried the specified channel. The conclusion reached^ 

W ^IZTJ* 5 ^ t0 maiatai,, ChannelS beCauSe we do not 8»™e *« channel specified 

and if we get complaints, we can obtain various details from the channel authorities themselves (e g can get 
; unavailability info from EBA etc). *■ s " s 

jH . May have audit details available for the flow control process, but this will not be processed by updating the stage 
=.=• status history details on the FT-TRANS record. J*"ung me stage 

' u^iageable) 1 ** 'k^^ ( ° Perati0nS C ° uld C,0SC * e channcl * 1 ueue to becomes 

• Urgent transactions; no automatic process to route transactions down a clear channel as opposed to a busy channel 

• Channels Already tried. 
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5. PROPOSED SYSTEI 

5.1 SYSTEM OVERVIEW/C&WcEPTUAL DESIGN 
5.1.1 Introduction 



a new 



Sv^f °!- EUr ° tranSaC ^° ns Z°' m S *">u S h F " FTS the clearing channel they go through will be chosen by 
Payment Routing process. This process will decide which clearing to use based on a number of factors. 

I^ 0 H U ^Tr, WiU \ C FTS PaymentS fl ° W after IDR ^ before Product generation (se diagram in 

Appends A). It has to go before Product generation as this is where the specific formatting for the different chlZb is 

to ensure ,hat as much valida,lon and general fom,aning is don * on Ae ^-Xr to L 

Sf? 5?! P ^ e "^ it Payment r ° Uting Payn,eDt *»* wil1 be set £o a default va,ue °f 'CLG-. Then Routing will 
change this to EAF, EBA etc. once the route has been decided. souring will 

transactions however ^ win have ciearing decided earuer - - *** «■» * 
a) t^^: snsssf ssr 0,6 Clearins member bank is not coimected to — ciearing 

|n b) those payments on which the customer has specified the clearing to be used 
c) Manual payments that have had a particular clearing specified 

P Payment routing will pick up all clearing transactions. For transactions with payment type of CLG it will try and decide 

W SSSTi; Transactions •t* Payn,ent rOUK SCt 10 3 pr °P er VaIue < EAF - EL ^ SNP «*• > already^ read by 
u the routing module but the logic within it that decides on payment routes will be bypassed. 7 

•K ^A^^ r t°V ead * e Routi =« module a record to the new flow control database file (FT-FLOW- 

TRANS) so that the transaction is mcluded in the Flow Control checking process. 

I?th fl r, C0Dtr01 ^ ChCCk StatC ° f V3rioUS Flow Coatro} balances and ei *« h°W the payment (because one 

£ of the balances would exceed the limit if we made this payment) or release the payment to Production^lratiol 

m ^y™^ going out to correspondent banks other than Chase FFT will have a pavment type of CPO Flow Control will 
jj3 treat each Correspondent as a separate channel and will maintain a balance for each. 

vTriou!^ ri yS 'T * Pr ° Vided 1116 US6rS ,0 CODtro1 * C P 3 ^ 6 " 15 held fa * e FI ° W Control queues. They will have 
™ *7*°"f. f 7 mOVm S ^ queues, like rerouting to a different channel, cancelling die payment 

totally, or sending the payment back to repair. ^ 

See diagram in appendix A for flow chart of the main FTS areas and where the new processes will fit in. 
5.1.2 Stage Status's 

As there will be three new 'stages* in FTS - Routing and Flow control - new FTS Stage Status values will be needed. 

369xxx - In delay awaiting payment routing 
373xxx - in or awaiting payment routing 
374xxx - In or Awaiting Flow control 

£ tlo"Z Su te nCedCd fOT l tCmS S ° thr ° Ugh neW processes Items d ° nt - « 6 deques, will go straight 
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Note that 369 is a delay status. 616 clearing payments will be delayed before Payment Routing instead of before Prod 
generation (see later for reasons)^*^ oa 




IDR. STRAIGHT THRUS, 
MA. CLC 



-STATUS = 370- 



Delay for non 
616, and 616 non 
clearing items 



STATUS = 370 



I — To MHS — 



Product 
Generation 



X-Border. 
Direct and 
Reimbursment 



-STATUS = 369- 



Delay for 61 6 
clearing items 



STATUS = 373 

r 



Payment Router 



STATUS = 374 

r 



Flow control 



-STATUS = 375- 



~ STATUS = 376_ 



Overnight reset 
of x border 



STATUS = 373 



-Same day x border status 373- 



5./i|2.i Active/Inactive transactions and Delay 

IJ ] ?™Z t]y *™ S * Cti ™ S ar u e <liv ^ and ****** updateable at any stage up to and including 370 delay. After this they are 
\ti inactive and cannot be changed or removed. y 

For the new system Euro clearing transactions will need to be inactive when in the Flow Control process Hence the 
payment Router wiH set transactions to Inactive. That is TRAN-LIVE will be space and TRAN-INACTIVE will be set 

to a new value of 07. 

Because of this a new Delay stage (status 369) will be put just before the Payment routing function. This will give Ops a 
delav « ^ 86 3 tranSaC& °° before il becomcs Revocable. These transactions will not then enter the ca^STO 
Ae «W« ^y™** 1 ™ <«* W then they are already inactive). Below is an overview of 

the changes required to FTS to process the new control totals for Payment Routing. 
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5.7.2.2 Local currency Cross b&^r payments 



Local currency cross border payments have two parts. On the first day they generate a MT100 swift and on the second 
day they generate a clearing item. These transactions need to be included in the Payment routing and Flow control 
process on the day that the clearing message is to be generated. 

Initially then, the transaction will bypass the new processes and go straight to status 370 and product generation The 
over night batch process that currently puts them back into product generation via status 375 will instead put them into 
Payment routing via status 373. y u 

The status's that X border will now go through are 

Status Description TRAN INACTIVE 

370xxx - In Delay 00 

375002 - Product generation Awaiting acks 01 

376xxx - Overnight hold 01 

373xxx - In or awaiting Payment Routing 07 

374xxx - In or Awaiting Flow control 07 

375001 - In Product Generation 01 

375002 - Product generation Awaiting acks 01 

Note that because of the 2 part nature of x border payments they will never go to TRAN-INACTIVE of 07 Instead thev 
go straight from 00 to 0 1 and stay there until batching (06). y 

g This means that 'CLG* payment types can go direct to Product Generation as well as going to Payment Router. 

Same day local currency cross border payments do not need to go through this process. Instead they will go straight to 
r- payment router (Note that this means the direct message will not go out until the clearing side of the transaction has 
i =? been approved through the flow control process)- 

U j 369xxx - In Delay awaiting Payment Routing 

374xxx - In or Awaiting Flow control 
v 375001 - In Product Generation 

\-h 375002 - Product generation Awaiting acks 

II I 

5.£u2.3 Direct plus Reinbursements 

03 61 6 Transactions that will generate direct and reimbursement messages (apart from local x border above) will RO 

trough payment routing and How control directly. That is they will go 369, 374, and 375, and will not go through 



5.1.2.4 Transaction validation in prod generation 

In the current product Generation transactions with Stage Status 370xxx go through various validation. Transactions 
with Stage Status 37axxx do not, because they used to be 370xxx and so have already been validated. 

As Euro clearing products will be set to 375 before they reach Product Generation they would potentially miss this 
validation. Hence the validation will be copied and included at the end of Flow Control. It cannot be put before the 
held queues because one of the checks is ensuring that the DOE is still open. 
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5.1.2.5 Transaction Inactive stah 



A new TRAN INACTIVE status of 07 will be introduced for payments in the Payment Routing or Flow control 
processes. This will be maintained as follows:- 

Payment routing 

Payment Routing will set Tran inactive to 07 on every 369 record it reads. It will update the control totals for 07. 
For every 373 record it will not change Tran Inactive as it is already set to 07 (see later). 

Product Generation 

Records read with Stage Status of 370 will currently be active and so Tran inactive be set to space. 
Records read with Stage Status of 375 will either already be 01 or 07 (if from Flow control). 

For all records read Product generation will set Tran Inactive to 01 if not already at that value. 
Overnight batch 

The x border over night batch program will be sending items 616 clearing items back to Payment routing and so will 
set Tran Inactive back to 07 for these. 

Online Flow control 

If an operator sends a payment back to repair the online programs will change Tran Inactive from 07 to space and 
make the payment active again. 

If an operator sends a payment back to payment Router Tran Inactive will not need to be changed as it is already at 07. 
Acknowledgement processing 

If an operator sends a payment back to repair this process will change Tran Inactive from 07 or 0 1 to space and make 
the payment active again. 



5JH3 Payment Type flow 

Euro payments in Chase FFT will go through Payment routing and Flow Control, some will go through neither, and others 
; ! = will go through just one of these. Which path a payment takes is dependent on when the Payment type (clearing channel) 
l=c is specified and by whom. 

| n 

42 Payments with specified payment route 

Some Payments will have the payment route specified either by the customer on the mcoming message, or by Operations 
during manual input. Within payment input and straight throughs validation will be performed to ensure the necessary 
data for that channel is held on the transaction. 



131 



These payments will go into Payment Routing but purely to add records into the Flow Control processing. No actual 
routing processing will be required as the route is already decided. 

Liquidity payments will be identified by having a new instruction type of 4t LQ*\ 

Payments with CLG payment type 

Payments that do not have the payment route specified by the customer or by Ops will have Payment Type set to CLG. 
For these Payment Input and Straight Throughs will ensure that there is at least one channel that FFT can use to get a 
payment to the Clearing Member specified. Because we dont know at this stige which channel will be chosen by the 
Router, validation will ensure that the necessary transaction data is available for every channel that can be used for this 
clearing member. 



i far: ctMneownTEwn^MRtrmc 
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The Stage status will be set to 369013 (or 370003 if next day x border). 

When they are released from F low C ontrol the Stage Status will be set to 375. , 

Thra product generation will f^^ese up as usual. (With new prod generation tasks^fc new clearings? E.g. F08H for 

Payments destined for a correspondent 

Payments destined for a correspondent rather than a clearing that FFT is connected to will have payment type of CLG 
Specific channel validation will not be done on these payments. 

These will still be picked up by payment routing and the payment type will be set to CPO. They will need to go throueh 
Flow Control as we need to maintain balances for our Correspondent relationships. 

CPOs 

Any Euro transaction that has a payment type of CPO will not be a clearing item. Hence they wont go through Payment 
routing or Flow Control (e.g. Credits down the payments leg). 



1.4 Payment Routing Process 

A new background task will be provided that will decide on the channel to be used for each 61 6 Euro payment This task 
will not be streamed. It will process transactions at the new stage status of 369, but only after they have been through a 
Delay period. It will also process next day x border items at stage 373, and these will not be delayed. 

^ If a valid channel is not available for the payment the router will send the payment back to repair. 
^ In order to decide on the preferred channel, the router will have to access new static data as follows:- 

Clearing Channel details. 

- As already mentioned both payment input, straight through processing and the router module at FFT will need to validate 
=; and process usmg channel specific information. These details will be held in a new table that will hold all the possible 

'1 ch ^ mels Aat f» b * use <* to clear Euros. Tnis will mean that the records will include not only the channels to which FFT 

- =? will be a member of. 

These table records will also be used to control which channels are available (open) for FFT at any point in time The 
-* records will also contain information that may be used by the router when deciding on the channel to use for the payment 
y (e.g.: any minimum- volumes/values for specific channels, cut-off times etc.). 

H See the detailed design section for more information. 



M: CtM«M0W3t7EM»*40«Ui7OOC 
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Clearing Channel Member details and preferred routing method. 

Within payment input, straight th^h and payment routing, FTS needs to be able to ch^fchich clearers a bank is a 
member of. These details will b ^^>" * new table (CMD) that will be maintained eit^^nually or electronically. 

The new table will also hold the details on the preferred routing method if the bank is not a member of a clearing to which 
FFT is a member. & 



5,1.5 The Euro Flow Control Process 



5. /. 5. 1 Lint it ch ecking 

Once a payment has been through Payment Routing it will enter the Flow Control checking process. Here the balances 
and limits at each clearing member bank, and debit credit cap will be monitored. 

There will be one program for each Flow Control check I.E. 2 programs in total. Each program will be designed such 
that it can be cloned by payment type or by a group of payment types. Depending on what static data is set up one clone 
processing everything could be implemented, or a maximum of one clone per payment type could be implemented 
(seven payment types times 2 programs = 14 new background tasks), or payments types can be group together for 
processing by one clone (e.g. one clone for both EAF an ELS). 

Each clone will operate on a timer basis. That is the tasks will not be kicked off by any other process (e g IDR, or the 
previous flow program). Instead, throughout the day they will turn themselves on, process any payments awaiting their 
attentions, and then go back to sleep. Their sleep period will be a fixed duration which will be parameterised and 
therefore changeable by Ops. It will also be possible to set a critical time period during which the sleep period will be 

g*? less. Up to 6 critical time period can be set per clone. 

£3 

The arrival of a credit will not trigger the Flow Control process. Instead the tasks will just wake up after their sleep 
| s 4 periods as described above. This is inline with how FTS IDR works. 

n i 

i a 

I j j Payments held in the Flow Control queues will be rechecked only when the tasks wake up. There will not be any special 

IjJ P ro = css,n S Jot recheckmg held items e.g. when a credit arrives. However, this will actually mean that they get processed 

j=i slightly before new transactions (within the Bilat) because they will be older and the oldest will be checked first. 

E There is no requirement to check held payments more often than this. 

HJ ^ 6 COmr0 , 1 ' P™"^ 1 ™ 3 "^ °"ly 2PP«« to Chase FFT branch. It may however, apply to other clearing branches 

i=i branch " CaSC thCn PrOCCSS bC mUlti streamed ^ we wi " have one P roce * P« clearing 

yi 

S usuTw^f* FI ° W C ° ntr01 ^ abCndS ° r fmdS CrT ° r ' ^ erTOr WiH 3ppear ° n ^ QueUC StatUS cnquky m 



5.7.5.2 Balance update for credits 

When a credit comes in a process will be needed to update the relevant Flow Control balances. To do this it will have to 
identify which clearing the credit came from, and which bank sent the payment into clearing 

Once this is known the process will be able to access the balances that need to be updated 

a) the balance for the Bilat relation ship in that clearing, 

b) and the balance for the Debit Cap for that channel. 

Initial Message processing (FTK1 1) will do this updating. This is earlier in the FTS process that the credit updates for 
IDR. IDR has to wait until FTS is certain that the credit will update a particular customer account number. Flow control 
however is not interested in the Credit account number, it is only interested in the fact that a credit came in from a 
certain clearing (LE the Debit account number). 
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5.1.5.3 Storing of Flow Contro^nits 

These will be stored on a n^Ws table. These limits will be keyed on the clearing^Siber bank to which we send the 

™^ ( ^" S termS ' WU1 USUally be PAYING BANK, though for local currency cross border it may be 
THEIR CORRESPONDENT Bank) and the clearing channel. V 

That is, the full key will be 
Clearing member Swift Address 

Payment type (ELS, TBF, CHE, etc. or the swift address of our correspondent bank) 
and the record will contain :- 

Balance Limit agreed 
Current balance 

Number of payments held due to this check 
Maximum payment amount allowed 

The limits need to be updateable quickly in a contingency situation. Also, although the Limits should be updateable the 
balances, and number of payments held figures should not. Hence the usual table maintenance system GPPM is not* 
appropriate for this data. Instead this table will be maintained by a new online application. 

5.JL6 Euro Flow Control (Online system) 

ri 

£ An online function will be provided for enquiring on and controlling payments held at the various stages of flow Control 

,,i checks. Access to this funcnonality will be via either one of two applications, Enquiry or Update. Users with Enquiry 

pj access will only be able to enquire on the Held payments in Flow Control. Users with Update access will be able to 

hi m °™ t0 T r ContTo1 Pay™** » Flow Control. All Held records on FT-FL O W-TRANS will be available for Enquirv 
I , | and/or Update. ^h 1 *" j 

\ By using this online system OPS will be able to :- 

^ | a) Select one of the clearing queues to display all the held payments 

lit b) ManuaUv Please any of the queued payments (down the channel) if required 

c) Manually put a payment back to the payment router (so a different channel can be selected) 

KeTOU *?Z back to module or releasing a payment from a queue will cause the bilateral & channel totals to be 

updated automatically. 

5.1.7 Product Generation 
Changes for 375 

At the moment every transaction will go to product generation with stage status 370. Some transactions will also go to 
product generation a second time with stage status 375. Product generation therefore does various processing on 370 
transactions that n does not do on 375s: - 6 
Validation of 

Account status 

DOE closure 

Product status integrity 

Set PROD-DELIVER Y-IND to 1 (so prod gen will read these 375 records) 
LICR updates 

As the majority of Euro clearing transactions will now bypass status 370 and go straight to 375, changes must be made to 
ensure this processing is done on every transaction. Hence this validation will be copied into a new module FTK0093 and 
put at the end of Flow control. 
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Changes for new payment type 

Product generation will need cha^H^Iightly to process payment type of CLG. These ^^Bive a stage status of 370003 
so that they will get processed by^Pt. The CLGs that hit Prod Gen will be next day IocMurrency cross border only 
(these initially bypass the Router and Flow Control). Prod gen needs to process them and then send them back to router 
(via 376) as CLG. 



5.1.8 Euro Payment Contingency (Online system) 

A contingency function is required to capture payments that have either been rejected at the clearing bank or errored at 
some stage of the payment flow out to the clearing bank, to enable them to be sent back to Payment Input or back to the 
Payment Router. 

This functionality currently exists within FTS for DM clearing. 

Currently there is only one option for DM Clearing. This will be changed so that operations can either go into DM 
Clearing, CHAPS clearing or French Clearing contingency functionality. 

DM Clearing Contingency. 

Current processing will remain as is. There will be a new option added where a payment(s) can be 
sent back to the Payment Routing module. 

CHAPS, French Euro and EBA Clearing Contingency. 

The option to CHAPS contingency print will still be available for CHAPS payments but a new option will be available 
Zl from ^ new S eneric 'Clearing Contingency' function for both the French and CHAPS and EBA payments to: 
[\ Send all rejected payments back to Payment Input for repair, 

["j 2. Send an individual rejected payment back to Payment Input. 

ifi 3 * Send other payments back to Payment Input (i.e. Product Delivery awaiting acks etc.) 

4 - Send one or many payments back to the Payment Router. 

5.1.9 Accounting changes for EURO clearing payments. 

U ^ Preferred Nostra for EURO payments at FFT will be changed to be a EURO Wash account. This will mean that all 
: n EURO payments that indicate the use of the Preferred Nostro will be processed through a common wash account. 
^ Payments could still be processed to NCU Nostro accounts in Payment input by the user entering the required NCU 
Nostro account number. 

Once the ACK has been received for the product sent, the correct Nostro account will need to be updated on the 
transaction details before the transaction is sent to awaiting batching (accounting update). The nostro accounts will be held 
on the ECC table per clearing channel. 



5.1.10 EOD 



Each department using FTS for processing transactions currently has to run an EOD function within FTS to check that 
all transactions are in a satisfactory status and to flag the department as closed within the system. This will have to be 
amended to look for payments in the Flow Control or Payment Router queues. 

On finding payments in these queues the EOD will not be allowed. In these situations Ops will have to cancel the 
payments. 



' ClM#C01IWTf»^a»J»7 DOC 
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5.2 Detailed Design 

5.2.1 Table ECC - Euro Clearin^hannel information. 

Both payment input, straight through processing and the router module at FFT will need to validate and process using 
channel specific ^formation. These details will be held in a new table (ECC) that will hold all the possible channels that 
can be used to clear EURO'S. This will mean that the records will include not only the channels to which FFT will be a 
member of. 

These table records will also be used to control which channels are available (open) for FFT at any point in time. The 
records will also contain information that may be used by the router when deciding on the channel to use for the 
payment, (e.g.: any minimum- volumes/ values for specific channels, cut-off times etc.). 

See Table description is section 5.4. for table details and layout. 

New routine will be generated to create and maintain new records on the table. FT4716. See document 4716.DOC 



I- J 

I s " 

Pi 

\ . : 
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5.2.2 Table CMD - Clearing channel member details and preferred routing method . 

Within straight through, payment input as well as in payment routing we need to be able to check which clearings a bank 
is a member of. To cater for this, a new table file needs to be set up that will allow for the maintenance of channel 
membership by paybank. Each Paybank/Channel combination will be held on a different record on the table file. This 
will allow for easier prioritising of channels when a paybank is a member of more than one clearing. A new module 
(FT4717) will be generated to create and maintain the details on this table. 

Paybank/Channel information can either be manually captured or an electronic batch process may be possible to capture 
channel membership details onto the new table from existing table information. If the electronic method is chosen, any 
changes to the clearing members will need to be made to the table from where the details are copied Special cases where 
details need to be added to the CMD file during the day will need to be captured and verified by specified person(s) who 
will need to ensure that the table where the details are obtained from is also updated. 

To help limit the complexity of the coding in the router and other parts of the system and to have a common interface to 
the paybank/channel details, it is planned to have all channel member details held on this single table file and to have 
each channel details conform to the same standard record format. This means that for example, German clearing member 
information, the current BZL codes will need to be converted into their SWIFT codes before updating on the new table. 
This process will need to be performed any time the underlying data changes. 

The loading of a clearing's members can be processed either manually or through the use of a batch program. The latter 
only being possible if the details already exist in some form on the mainframe or the details are provided electronically 
from the clearings themselves. For situations where the details can be automatically loaded, a new batch program will be 
required to load the details onto the new CMD table. Presently member details are maintained for EBA/ECU (assumption 
is that EBA/EURO will hold details in the same format) as well as EAF/ELS on the FTS-TABLES and will therefore be 
loaded by a new batch process onto the CMD details. The field CLEARING-MEMBER-CAPTURE will be used to 
identify which of the channels will be captured manually and which will use the electronic batch method. 

The new table will also hold details relating to the preferred routing method if Paybank/'Their Correspondent* is not a 
member of a clearing which FFT is a member of. If this situation arises, a new record will need to be added to the CMD 
table records that will indicate whether the Paybank/'Their Correspondent' wishes to receive its funds (from CHASE 
FFT) through TARGET or through a CHASE correspondent in the clearing they are a member of. These details will need 
to be maintained manually through a new application that will validate that if the paybank is a member of a clearing 
which FFT is a member of (i.e. record exists for paybank/channel combination), that a preferred payment method record 
is not entered. 

Preferred payment method record will either be Paybank/'TGT' for routing payment through TARGET or 
Paybank/'COR* if a correspondent should be used. The EEC table will not have a record ofr TGT or COR. The 
validation for the CMD table will accept 'TGT* and *COR' as valid channel details. 
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Validation needs to be included to: 

• '' Ensure tnat when TGT or Gg^V input that the 'Destination Clearing' is supplied. 

• Validate that the destinaric^^Mng is valid (i.e.. record on the channel file) 

• Validate that the destination^^aring for a TGT record is a valid RTGS clearing. 



2.3 FT4701 - New Batch program to load clearing member details for EBA/ECU (EURO) 

Member banks of EBA/ECU are currently held on file in the ECB table (FTS-TABLES). A new batch program wiU be 
generated to copy the required ECB details to the new CMD table. 

When changes are made to the ECB table the batch module will need to be run to update the new CMD details. 

The method used to hold clearing member details is to specify the SWIFT address of the member bank or a portion (first 
6/8 etc. characters of the SWIFT address). If the table specifies a portion of the SWIFT address, this would mean that any 
given SWIFT address whose first x characters match with the first x characters specified on the table would be regarded 
as a member of EBA/ECU. Before a SWIFT could be regarded as a member of EBA/ECU, the details on the ECB table 
need to be searched further as some exceptions to the general details supplied also exist. This is explained easier by way 
of an example. 



A small extract from the current ECB is shown below; 



ISwiff Member cod© 


Exception indlcafor 


DEUTDEFF 




DRESDE 




DRESDEBS 


E 


DRESDEFH 


E 


ESPCESMM 





1 ! 

Assuming we have two SWIFT address, DRESDEFT001 and DRESDEBS001 , to validate if they are members of 
EBA/ECU clearing. 



Example 1: DRESDEFTOO 1 . Masking to the record DRESDE which would indicate that the address is a member. Further 
checking however still has to be performed to ensure that there are no exceptions to this data. Two exceptions are found 
indicating that if the first 8 characters of the SWIFT are either DRESDEBS of DRESDEFH then this is NOT an 
EBA/ECU clearer. In this example, as the SWIFT does not match either of these cases, DRESDEFTOO 1 is a member of 
EBA/ECU. 



Example 2: DRESDEBS001. Masking to the first record DRSEDE indicates that the address is a member of EBA/ECU 
Validating further a record DRESDEBS is found which masks to the SWIFT being checked and as the exception 
indicator is set this would mean that the SWIFT being validated is NOT an EBA/ECU clearer. 

To limit the complexity of the router and other modules, member details of the EBA/ECU (EURO) would need to be 
loaded by a batch routine that would look at all the possibly SWIFT addresses (could this be narrowed in any way to only 
the possible EURO clearers) and validate whether it is an EBA/ECU member. If found to be a member, then the full 
paybank address and channel details would be added to the new channel member table. 
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ECB TABLE ( ECU clearing memb ers^ See appendix R 



Program : FT32 82N1 - Dete 



ECU clearing banks from SWIFT address. 



Program : FT32 82P1 Version : 2 

0010 1 #FT3262-PARMS 

0020 2 # SWIFT -ADDRESS 

0030 R 2 # SWIFT -ADDRESS 

0040 3 # SWIFT -BANK -COUNTRY 

0OSO 3 #SWIFT-CITY 

0060 3 # SWIFT -BRANCH 

0070 2 # CALLING- MODULE 

00 8 0 2 #USERS-DOE 

0090 2 fc EB A- CLEARING -BANK- YN 



A 
A 
A 
A 
A 
A 



Y= CLEARING BANK or N=N0T A CLEARING BANK 

5.2.4 FT4702 - New batch program to load clearing member details for German clearing (EAF/ELS). 

Member banks of EAF/ELS are currently held on file in the ECB table (FTS-TABLES). A new batch program needs to 
be generated to copy the required ECB details to the CMD table. 

German clearing do not use the SWIFT address to identify the members of their clearing but use a BLZ code instead. As 
the new channel member table will be keyed on the SWIFT address, the BLZ code will need to be converted to the 
corresponding SWIFT address to use before the store to the table. 

Details on which bank is a member of German clearing and their associated SWIFT address are currently held in the 
BCL and SWC tables. (FTS-TABLES). These details will need to be loaded onto the new channel member table using 
the paybank SWIFT address/channel details. 



Hi 



The SWC table contains the Swift codes for all the banks that are either directly or indirectly linked to German clearing. 
This table data will be used to populate the CMD table. 



542J5 Initial message processing - FTKOOll 

5JT.5.1 Update flow control details for incoming credits. 



iil 



This will have to be changed to update the Flow Control balances for Credits. It wiU identify the Channel and the Bilat 
that the credit came through. Once these are established it can read the two balance records on FT-FLOW-CONTROL 
using the keys :- 



: Key field names . 


Values for first record 


Values for 2rd record 


; Bilat identifier. 


identifier for this Bilat 


default value XXXXX 


- Channel ■ ' ^>y'* 


ELS, CHE, orTBF 


ELS, CHE, or TBF 



and update the balance, and the no and amount of credits 

If a credit comes in for a Bilat that hasn't been set up with static data FTS will ereate the required record as per the 
requirements laid out in section 4.0. 



If a credit comes in from a correspondent rather than direct from a clearing member, no balances will be updated. 



Dm Clearing messages: 

For DM clearing messages the clearing channel and the paybank will be identified in the same field 
on the INCOMING-MESS-RECV-FTS file, APPLICATION-AREA-1. 
Clearing channels will be either 1 .) GA for EAF 

2. ) GT for ELS (urgent) 

3. ) GE for ELS (not so urgent). 
Paybanks will be identified by the BLZ code. 
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Crtaps/EBA/French Clearin^^feages: 

For all other clearing mcssag^^Hblearing will be identified by the DELIV-SYS-Iti^^Pie paybank 
will be identified by the sender^wift address in STID on the INCOMING-MESS-RE^^FTS file. 



2.5.2 Clearing channel specific details. 



Sending Bank 




Chase FFT 





Tag 72 details for transactions received by Chase Frankfurt can 
have one of the following possible contents: 

- No channel specified 
-/NET/or/RTGS/ 

- /NET/ccc or /RTGS/ccc 

- /NET/nnn or /RTGS/nnn 
ccc = Channel to which FFT is a member 
nnn = Channel to which FFT is NOT a member (Will not 
be catered for by FTS.). 

For FFT processing, need to set the payment type to *CLG* for those incoming transactions that do not have TAG72 
channel specific information present. 

FTS will allow for the flexibility to accept channel specific information (e.g.: /RTGS/ELS) to be processed from CCAP, 
SWIFT, MULTICASH, Direct Payment and manual payment instructions. 

* FTS will search for the two new keywords /NET/ and /RTGS/ in TAG72. If the customer inputs these keywords 

7 incorrectly as say /TRGS/ FTS will not recognise it as a keyword and instruction will processed as a 4 CLG' payment- 

1 type. 

If channel specific details are found in TAG72, a new field FT-CLEARING will be populated with the relevant details. 

* FTK001 1 needs to examine each TAG72 line (1 thru 6) for the keywords /RTGS/ and /NET/ if found update FT- 

k CLEARING. If the channel type keywords are found, FTK001 1 needs to ensure that if channel specific information is 

also supplied that this is also updated to the new field. Only the first find of a keyword will be processed. If two clearing 
k channel details are input by the customer only the first will be used. 

h NB: If FFT is NOT a member of the channel specified, the channel specific information will be removed and the 
1 instruction will be processed as a 'CLG' payment and the router will honour the channel type details only. 

E.G.: /RTGS/ELS (If the character after the /RTGS/ is not a space and there are at least 3 characters, FTS will assume 
that channel specific information has been supplied. If not, then only the channel type will be populated. 

Examples : 



^ihcomih<j.TAG72 / "= v ,7 




/RTGS/ELS 


/RTGS/ELS 


/RGTS/ELS 


Blank 


/NETEBA 


Blank 


/NET/EBA 


/NET/ 


/NET/EBAEAF 


/NET/EBA 


/NET/EBA/RTGS/ELS 


/NET/EBA 


/RTGS/QWE 


/RTGS/ (assuming QWE is not found on ECC table). 
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5.2.6 Payment Input - Gener ; 

Customers must be able to specify the channel they wish to process a payment through. A new Held will be required to 
capture and mamtam th.s detail. This new facility will not be actively marketed to customers, but will be provided to Sve 
flex,bihty to allow the specification of any of the clearing channels to which FFT will be linked. g 

s^o -nr^r ?r C T ed ab ° Ut WWch dearinS * C Paymem is IO be processed *™&> * e Payment-type will be 
set to CLG For this default payment-type, once the transaction gets to the router phase, the system will decide (based 
on vanous rules), which of the available clearing channels the transaction will be processed through. 

New Fields required for payment input: 

fl"^x^^? (A9) " ^ available at NON-FFT branches. (e.g./RTGS/xxx or /NET/xxx) 
URGENT-IND ( A 1 ) - Only available at FFT. 

FT-TARGET (A 1) - Only available at FFT. Not input by user but is an internal field for FTS. 

■ C *Z T 111 ^ bC aUowed / or EU RO ('IN' currency) transactions and will only be made available to Chase FFT valid 
in FFT. Instructions inmated m FFT could be for any currency including NON-EURO currencies (e.g. USD) These 
instruction would not be sent to the router as it would be a >CPO' to 'Our' Correspondent for that currency. 

It " CP ?'u iS ™ PUt " P yT ent ^ Wfll aSSUme ,hat is XOT a clearin g instruction and will not be processed 
ftrougb . the router and flow control modules. If the instruction is to be processed though a clearing channel] the payment- 
type w,ll need to be input as CLG' or one of the clearings to which FFT is a member Payment 

Each of the clearing channels will have a unique FTS payment type assigned. The 6 current clearing channels being: 





Payment Type 


Status 


German NET clearing 


EAF 


Current 


German RTGS clearing 


ELS 


Current 


French NET clearing 


SNP 


New 


French RTGS clearing 


ITBF 


New 


Chaps EURO RTGS clearing 


CHE 


New 


EB A/EURO NET clearing 


EBA 


New 



The followmg discussions affect both the single and three screen payment input processes. Issues that affect only single 

T^JSTi^ l m f m latCr SeCti ° n bCiOW - AU 8eneral c °mm«»s are concerned with processing at fA 
The only Non-FFT changes are discussed in the three screen payment input section for Non-FFT processing 



5.2.6. J Instruction type for Liquidity payments. 



A new Instruction type for the liquidity payments will be made available to FFT payment input. New code = *LO* If 
SLS^S S^"*' ^ CM ^ ^ * CLG ' ^ W0UW haVC <° * " RTCS ^mSbtian 

5.2.6.2 Urgent Indicator. 



fl ^ (B ^ Ch 6 ' 6> " 3 Way t0 Change fte pr0CeSSm 8 P rforit y for t-n-ctions 
CT l^ n, C ° ' Pr ° CeSS - °" Ce a h « processed through the router and has been passed to 

flow-control, all Urgent transactions will be processed before any Non-Urgent transactions, (see Flow-control 
document for more detailed discussion). 

Note the router will NOT do any special processing for the urgent indicator. 
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5.2.63 Correspondent details reaped. 



reduce i 



If the payment type is set to (default payment type requiring the router to decide on the channel to be used), then 

Paybank/'Their correspondent' details need to be obtained as this detail will be used to decide on whether 
Paybank/'Their correspondent* is a member of a clearing channel of which FFT is a member. If no Paybank/'Their 
Correspondent' details are entered, payment input will need to attempt to automatically derive Paybank/'Their 
Correspondent*. If the Paybank/* Their Correspondent' cannot be derived, then the transaction needs to be sent to repair 
so that the details can be input. (FT-Correspondent could also be updated by OPS so as to allow auto-derivation). 

Current validation at payment input includes a check that if the Paybank is in the same country as the pay currency 
then the correspondent details are NOT to be entered. In the EURO environment, this will mean that if the pay bank is 
in any 'IN' country and the pay currency is the EURO or any 'IN* currency, then the correspondent details must NOT 
be entered. (See MT100 usage SDIP for details on changes). 



5.2.6.4 Validation to ensure that sufficient details are captured at payment input 

At payment input and straight throughs FTS needs to ensure that sufficient details are captured so that once the 
transaction gets to payment routing, the router will have sufficient details to choose any of the available clearing 
channels without having to send the transaction back to repair to obtain further details. 

To limit the amount of data that needs to be captured, the validation process will need to ensure that sufficient details 
are entered to process through any of the clearings to which the paybank/'Their Correspondent' is a member of. This 
Q1 will mean that if a paybank/'Their Correspondent' is a member of only one clearing, the validation will ensure that 
C3 sufficient details are entered to process through only that clearing. If a paybank/'Their Correspondent' is a member of 
i B& more than one, validation will ensure that sufficient details are entered to send through any of these clearings. 
M 

n j Validation will perform a common module and specific clearing validation for each of the clearings to which a 
1 ; | paybank/'Their Correspondent* is linked. 

Each of the clearing tasks needs to supply their data requirements so that they can be consolidated to ensure that all 
relevant details are captured in payment input 

Z Module will be a COBOL program so that it can be called from Natural or COBOL. 



5J2I6.5 Identification when TARGET is to be used. 

FTS will need to identify when target is to be used as extra details will be required to ensure that when the product is 
generated the correct TAG information is available. To allow for efficiency, the decision whether TARGET is to be 
used or not will be made in straight throughs and payment input. If TARGET is identified, a new field FT-TARGET 
will be updated to indicate so. This field will then be used to ensure that the correct details are available/obtained and 
mapped to the outgoing message. 

Decisions on when TARGET is to be used. (Instruction-Type of *LQ' indicates a Liquidity Payment) 





Decision .. 


Remarks : y&r: . " . ; - : / - 


1 


Instruction-Type = 'LQ* <and> 

Channel has been specified, (must be an RTGS otherwise input is invalid). 
Note: *LQ* with Payment-type = *CLG* is invalid. 


TARGET Payment 


2 


Instruction-Type NOT= *LQ' <and> 

Paybank/'Their Correspondent* is not a member of clearing of which FFT is a 
member <and> 
Payment-Type = *CLG\ 

Note: Preferred payment option will be held on the CMD table 


Obtain details whether 
PAYBANK/'Their 
Correspondent' prefers 
TARGET or corr. 
payment. 


3 


Instruction-Type NOT= *LQ* <and> 

Correspondent is a member of clearing of which FFT is a member <and> 
Payment-Type = 'CLG* 


Not a TARGET Payment 
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Instruction-Type NOT= 
Correspondent is a memj 
Payment-Type indicate 
Note: This facility will 



LQ' <and> 

pf channel of which FFT is a member. <and> 
f a channel to which the corr. is not a member, 
e available in Payment Input, not straight througfi! 



1 o^Pue 




TARGET 



Their Correspondent 
(Only a Member of 
ELS) 



FFT and 'Their Correspondent' both 
are members of ELS. FFT input 
indicates to use TBF. As "Their 
Correspondent is not a member of 
TBF the instruction will need to be 
processed through TARGET. 




5.2.6.6 Validation when TARGET indicator can be used. 



Validation needs to be included to check when the TARGET-Indicator can be set to indicate that the transaction needs 
to be processed through TARGET. The TARGET-INDICATOR will be made available for input in both single and 3 
screen payment input. Validation will be included to ensure that the user does not request an invalid request. 

When a payment type has been input (i.e. a channel has been specified), FTS will need to lookup on the new CMD 
(clearing member details) table for a record using the paybank and channel (payment type) that has been input 

IF the TARGET-INDICATOR — *Y* 

eayment-tvne input must an *RTGS' rlenrer 

Read the clearing channel table (ECC) record for the clearing input. 

If record is found validate that the CLEARING-TYPE is an 4 RTGS\ 
If no record found, error as clearing input is not valid. 

Qnce the Pavbank/ "Their Corresnnn dent ' has been input. 

Read the clearing member details table (CMD). 

If a record is found for the Paybank/'Their Correspondent '/Payment-type combination. This indicates 
that the paybank/'Their Correspondent' is a member of the channel requested and therefore the 
TARGET-INDICATOR should be set to 'N'. 

IF no record is found, this indicates that the Paybank/'Their-Correspondent' is NOT a member of the 
channel requested. 

If a record is found for the Paybank/'Their Correspondent ' indicating TGT or COR. Then payment- 
type needs to be set to *CLG' and the TARGET-INDICATOR set to *N' 

If Paybank/'Their Correspondent ' is a member of another clearing of which FFT is a member, this 
could result in the scenario 4 discussed above. FTS needs to validate that the clearing to which the 
Paybank/'Their Correspondent* is a member of is NOT available (check against the Clearing-Status 
data on the ECC table record for the clearing). If all clearings to which the Paybank/'Their 
Correspondent 1 is a member of are unavailable, then the instruction will be processed through 
TARGET and TAG54 details will be populated. 

If no record found on the CMD table, error message as require at least one method of payment. 
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5.Z 6. 7 TA G54 - Destination central clearing bank details. 

When instructions are to use ^JLt, extra details need to be supplied to the clearinj^hich the instruction is sent 

FTS will look up the details on the new CMD (Clearing Member Details Table) and if no record is found the transaction 
will be sent to repair. If a record is found there are two possible outcomes. The first indicating that the correspondent is 
a member of a clearing to which FFT is a member, or the second where the correspondent is not a member of a FFT 
clearing. In the later case, funds can be transferred in one of two ways; 

1. Through the use of TARGET. 

2. Through the use of a Correspondent- 
Use TARGET 

When messages are sent to a clearing that are to use TARGET, TAG54 on the outgoing instruction needs to be 
populated with the Central Clearing Bank SWIFT address of the destination clearing. To obtain this information, FTS 
will need to process the following: 

• Obtain the details from the CMD table file for the paybank 
E.g.: <PAYBANK>TGTO IPTE This indicates that for <PAYBANK> FTS must issue an instruction 
that will use TARGET and the destination RTGS will be the PTE clearing. 

• Use the destination RTGS and obtain the clearing channel table record for that clearing. 

• Data on the clearing channel record will indicate the central clearing bank SWFT address for that clearing. 

Our correspondent details. 

If a record is found on the CMD table that indicates COR as the channel, this will mean that the funds need to be 
fransferred using a correspondent relationship. This will occur if the paybank is not a member of a clearing to which 
FFT is a member. 

The details about which correspondent to use will be held on the Clearing channel table records. To obtain this 
information, FTS will need to process the following: 

• Obtain the details from the CMD table file for the paybank 
e.g.: <P A YB ANK>COR0 1 PTE This indicates that for <PAYBANK> FTS must issue an instruction 
directly to our-correspondent for the PTE clearing. 

• Use the clearing channel specified on the CMD record. 

• Data on the clearing channel record will indicate the correspondent to which we need to sent the instruction 
( Our-Correspondent T ) 
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5.2.7 Payment Input - Three s creen ^ ,. 

5.2. 7.1 NON-Frankfurt branc^bcessing. 

1 . Customers must be able to request a specif.c clearing channel to be used and this will need to be captured at input 
in a new field At manual input stage, validation will be included to ensure that any channel specific information 
that „ requesKd is valid. Tins will be checked against a new clearing channel table that is to be set up to Sd 
channel specific information (see Table section above). The validation does not need to ensure that FFT is a 
member of the channel, only that the channel is a valid channel 

2. No validation will be included to check whether the customer is allowed to specify channel specific information or 
not. ,.e.: Anyone can use the facihty. The control will be mat the facility will no, be actively marketed to 
prying reaS ° n V3lidatinS data * * at 0PS d0 not ™ h to ™duly afTect the straight through 

3 ' y a ntm d n C DeedS ,0 1* Va " dated againSt CmTenCy h0lida y table (' CUR ' Table >- I E -^ ^ *e payment is for 'IN' 
or EURO currency then payment input only needs to ensure that the EURO clearing is not on holiday (all 'IN' 
currency 'holiday dates will be set to the EURO holiday schedule on the new 'CUR' holiday table, (see FTS EURO 
Task 5. 14 for more details on the holding of holiday dates) 

4. 'Their' Correspondent details are only required for X-Border instructions. If the instruction is not a X-border 

payment, the router will need to use the Paybank details as the bilat details (used for reading the CMD records) If 

InJr 1 I- Payi ??? iS ™.° J rder Payment ' * e ""^ C °raP°°d=nt' values will be used for bilat processing 
and the reading of the CMD details. 3 

5 The URGENT indicator and TARGET indicator will not be available to Non-FFT branches 

2^ Tf 1 C r 111 ^ T PPCd t0 TAG?2 ° n thc OUt£ °^ messa S e t0 FFT- If * e instruction requires a 

131 Direct to the beneficiary bank and a Reimbursement to FFT, only the reimbursement will have the channel 

q specific details mapped to TAG 72. wu»c. 

hit 

5.2*7.2 Frankfurt processing. 

W 1. FFT will only be able to process EURO clearing instructions through one of the valid FFT channel routing 

U 2. ECS £r ' mCmber " ™ S ^ C ° ntr0,led * USiDg ' TTY ' - Me - 

U 3 - ^^S!SS f 'CLG' which will then force the transaction into the payment routing process 

PJ 4. If the default payment type 'CLG' has been specified, payment input needs to ensure that at least one channel is 

£ ^ ri7 0Ut t*u tTanSaCti0n ttaw * h - Needs to ^lidate against the CMD table. Would also need to ensure 

"3 Zl iS'i W , a , "'""P^^^ARGET could be used. The validation will only check to ensure that at 
least one channel is available to send the payment through. This will be performed by checking to see if we have a 

03 5 ITr^T f^T k * Me - ValidatiOD ° n H ° lidays > Crashed channels ete " wi » ^ performed by the router 
5. If payment-type has been set to CLG', FTS will need to read the available channels for the Paybank/'Their 

?Sf°p T ™ C SUf5RCient dCtailS 316 aVailaWe l ° prOCeSS ^ P*^* ""omit any of the channels 
to which the Paybank/'Their Correspondent' is a member. 

A new instruction type will be made available to indicate if a payment is a liquidity payment. New code 'LQ' 
An Urgent indicator field will be made available to manual payment inputs at Frankfurt. This will be used by the 
flow-control process to change the processing sequence for the transactions. (Urgent will be processed before non- 
urgent. Urgent indicator will only be made available for manual payment input at Frankfurt 

X'v i WM ^ defaUlt , t0 ' N '- ° Perat ° r Wi " need 10 cha "S e to ' Y ' ,0 mat taction needs to 

nave a higher priority once reaching the flow-control process. 

If the instruction type is set to 'LQ' (Liquidity Payment), payment input will automatically set the Urgent 



6. 



10. 



No validation will be mcluded to ensure that the Urgent indicator is only used for the liquidity payments. The 
urgent indicator will be available to all manual inputs. 
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5.2.7.5 TARGET-INDICATOR gjmation 



Processing problem with 3 screen payment input and the validation of the TARGET- INDICATOR. This is because the 
paybank details are only input in the third screen by which time the payment type and TARGET-INDICATOR have 
already been captured. 

If the combination of Payment-Type, TARGET-INDICATOR, and Paybank is found to be invalid the user will be 
presented with an error and request them to return to the first screen to correct the Payment-type/ TARGET- 
INDICATOR inputs. 



SCREEN 1 



SCREEN 2 




Payment-type and 
TARGET-INDICATOR 
are input in this screen. 



SCREEN 3.1 



SCREEN 3.2 




Different third screen 
inputs are used depending 
on the payment-type. 



SCREEN 3 J 



SCREEN3.N 



Validation on TARGET-INDICATOR.: 



Third screen input accepts the paybank details 
and needs to validate the Payment-type, 
TARGET-INDICATOR and paybank. 



Validation will need to be called once the Paybank/'Their Correspondent' details have been input. See sections above for 
deail on validation. 



5-fi7.4 New Three screen completion module for payment-type 'CLG 9 

; A new completion module for three screen input will need to be generated to complete the payment input requirements. 

] k This new module will need to capture sufficient details to process payment through any of the available clearings. 

J * The new module will need to ensure that any special processing currently performed in the modules for CPO German 
j*- and CRI/SIT (French) cleraing are included in the new CLG completion module. 

Current completion modules are: 



decision 1 . j-f^'Vt; 1 ' ,>v * -. 


Routine called 


Remarks7ig^;7;; X^C ' :C 


X-BORDER-IND = '1/ 


FT4050 


? 


PAYMENT-TYPE = 'MPO* or *CPO' 


FTUN863 


Include in New Module 


PAYMENT-TYPE - *BP* 


FTUN864 


NO 


PAYMENT-TYPE = l CHP' 


FTUN865 


NO 


PAYMENT-TYPE = *CHQ' or 'DFT T 


FTUN866 


NO 


PAYMENT-TYPE - 'EAC\ 'EAF\ 'ELS', 'DD\ 4 CHK* 


FT3417 


Include in New Module 


PAYMENT-TYPE = 'Sir 


FT3591 


Include in New Module 


PAYMENT-TYPE = *DOM* 


FT4407 


NO 


PAYMENT-TYPE = '1AT and Branch = '60 T 


FT4418 


NO 


**NEW - PAYMENT-TYPE - 'CLG' 




New module. 
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Current details captured on completion modules for various payment-types 
GERMAN CLEARING <Ft{ 



BRCH 616 DOE 8 70 



FTS MA^^PPT SWIPT INPUT 
STAGE 2 - Dti CLEARING 



15i41 ON 2JDec97 



THAN REF SS68411 BRANCH. 616 INTERNAL- IND t 
CLEARO : BANX CODE: 

AWB DETAILS 
INFORMATION TO PAYEE 
MESSAGE TYPE : 0 



T20 -. 

T32A: 

saw : 

Ho aessage available 



Original Message 

Priority 



PF3~Back PF5=Tog ?F12»Hnu 



FT3417M1 PT3417 020 



i PF7-PREV PFB-NTXT 



CPO/MPO INSTRUCTIONS fFTTJN^J) 



BRCH 671 DOE 2 OS FTS M/ PAYMENT INPUT- STACS 2 -PAYMENT ORDERS 15, S3 ON 03CCT97 

I^S^S! REPEREHCE ' "63412 TRANSACTION BRANCH, 671 PAYMENT TYPE = CPO 
PAYING BANK LOCATION, 0 00 

A/C INPOi- 
A/C WITH BANK 



THEIR CORRESPONDENT 



BY ORDER OF 



LOCATION: 000 



BENEFIC 



CORRESPONDENT CHARGES BEN SWIPT PRIORITY MPO (Y/N) t - PRINT LOCK • 

THIRD PARTY CABLE REQUIREMENTS,- WHOM i NUMBER OP CONFIRMATIONS--* 

BY ORD N INST OUST Y THEIR CORR PAY BANX 

SWIFT MIDLC322 
TELEX W001647 
CHIPS 23-40 

PPl-Back PPS-Tog PF12-Mnu 

^ FTUM8 631 FTUN8631044 



T20 t 
T32A: 
SRM .- 

No message avail Able 



Original Message 

Priority 



PP7-PREV PF8-NEXT 



The new module will capture generic details that will help ensure that once the transaction reaches the payment router 
sufficient details will be available to process the payment through any of the clearings to which the paybank/'Their ' 
Correspondent' is a member of. In the new 'CLG' completion module, the Paybank/'Their Correspondent' details will 
be input. The module will obtain a list of the clearing to which the paybank/'Their Correspondent' is a member of and 
will ensure that sufficient details are captured to process through any of these clearings. Validation will be contained in 
a new validation module that can be called from Payment input, Straight Throughs and the Payment Router 



Screen 1 



Screen 2 



Completion Modules 



Validation Modules 



MPO/CPO 




German Clearing 



CHP 



CLG 



Common 



MPO/CPO 



etc.. 




etc.. 



Ct*»ooi«,TS**.<»«jjf7 OOC 
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5.2.8 Payment iriput - Single sc 

The following changes are to be 



2. 
3. 

4. 

5. 

6. 
7. 
8. 
9. 
10. 



for Frankfurt processing only. 

FFT will only be able to process EURO clearing instructions through one of the valid FFT channel routing 
options, that is a clearing to which Frankfurt is a member. This will be controlled by using the existing 4 TTY' 
table. 

Value date processing as per NON-FFT. 

No validation will be provided to ensure that the customer is allowed to specify channel specific information (See 
Three screen input above for more details). 
Validation for 'CLG* see three screen discussion above. 

If 4 CLG* payment type has been entered, FTS will require the user to input a valid 8 or 11 character swift address 

in TAG 57 details. No CLR or BANKCODE details must be input. 

Urgent indicator processing see three screen input discussion above). 

Positioning of urgent indicator on the single screen see Appendix G. 

A new instruction type for liquidity payments *LQ' will be supplied. 

If the instruction-type is set to *LQ' FTS will automatically set the urgent indicator to * Y\ 

This input process is only available for certain branch payment type combinations. FFT (616) will need to be 

updated to include the new payment types for French,EBA and Chaps EURO as well as for the default *CLG' 

payment type. Currently (Dec *97) valid combinations on the 'TTY' table are: 





Branch 

2M 








616 . 


m 


CHK 




X 




CHP 






X 


DD 




X 




EAC 


X 


X 




EAF 


X 


X 




ELS 


X 


X 




IAT 


X 


X 


X 



5.2.9 Straight through Payments 

H j Each of the clearing channels will have a unique FTS payment type assigned to them. See payment input section for more 
details. 

5-^-1 NON-FFT processing. 

1 . Straight through at non-FFT branch. Need to obtain any /NET/ or /RTGS/ details and generate on outgoing 
message to FFT. Clearing channel details will be populated in the TAG72 field. 

2. No validation to check whether customer is allowed to specify channel specific information or not. (See Single 
screen input above for more details). 

3. Value date will need to be validated as per Payment input. 

4. The payment route specified by the customer using /RTGS/EBA is the DESTINATION clearing rather than the 
INPUT clearing. This is because the Input clearing only affects Chase's liquidity. The Destination channel affects 
the customers liquidity. E.G. if RTGS/EBA is specified Chase could pay through CHE, and Target, to EBA and 
hence to the correspondent bank. This then allows for clearings to be specified that are not clearings that Chie 
FFT is a member of. Like in the Portuguese example /RTGS/PTE would go Straight Through as these other 
clearings would be set up on a new validation table. 

If the channel specified by the customer is invalid (e.g./RTGS/XYZ), this will NOT be sent to repair. In this case, 
FTS will honour the /RTGS/ request and the router will then decide on which /RTGS/ to use. This will mean that* 
no validation for the channel specific information will be required at any NON-FFT branch. 
Validation for 4 CLG' see three screen discussion above. 



5. 



6. 



Version 1.0 - Page: 39 



5.2.9.2 FFT Processing. 



o^^^spe 



at least ( 



1 . For instructions that do nffl^pecify the channel to be used, need to check that atTfSst one channel is available to 
be used to route through otherwise send to repair. 

2. Value date will need to be validated as per Payment input- 
Straight throughs needs to set the payment type to 4 CLG\? 

TAG72 channel specific data possible scenarios (Corr. = Their correspondent): 



II 


f Taa72 channel :: . . 


Descifef/on 


Sfrofahi Throuah 




No details 


No Channel information 
supplied 


Payment-type = *CLG* 
Ensure that at least one record 
on CMD table. 




2 


/RTGS/ 


Channel type supplied 




The router will only use 
RTGS clearings which the 
paybank/'Their Corres* is a 
member of. 


3 


/RTGS/XXX 


XXX Tint on tipw c 1 f*a i~in u 

table (ECC). Assumption is 
made that the customer has 

<?lir>nl i pH sti invalid ol^nrinCT 
rr **n ui vaiiu wi&allilg. 


aaa lb icmovea ana 
Payment-type = 'CLG\ (i.e. 
as per #2) 




4 


/RTGS/EAF 


EAF is a valid channel but it 
is not an RTGS. 


EAF is removed and 
Payment-type = *CLG' 
(i.e. as per #2) 




5 


/RTGS/ELS 
Paybank/Corr. is a 
member of ELS. 


Valid channel 


Payment-type = 'ELS' 




6 


/RTGS/ELS 
Paybank/Corr. is 
NOT a mem. of ELS. 


Valid channel details but the 
correspondent to use is not a 
member of ELS clearing 


Payment type = 'CLG\ 
Remove the channel data 
(ELS). 

(i.e. as per #2) 




7 


/RTGS/TBF 

Corr. NOT a member 

ofTBF 


Invalid input from user. DO 
NOT USE TARGET. 


Payment-type = *CLG* and 
remove channel details, 
(i.e. as per #2) 




8 


/RTGS/PTE 


PTE valid channel found on 
the channel file. Unable to 
identify whether 
Paybank/'Their Corr.* is a 
member of PTE clearing or 
not. 


Payment type set to *CLG\ 
Remove the channel data 
(PTE) and process as /RTGS/ 


Router will use new table to 
identify what the 
PAYBANK's preferred 
method of transfer is. 
TARGET or Correspondent. 
TARGET - Update new field 
FT-TARGET. 
Correspondent - look on 
channel table file to obtain 
*Our* correspondent details. 



Scenario 1. No channel specific information provided. 

This should be the most common situation as not many customers will be given the ability to request channel specific 
information. In this case, the decision on which channel is to be used will be postponed until the payment router. The 
only validation required in this instance, will be to ensure that at least one channel could be used for routing the 
payment. This will entail obtaining 'Their Correspondent* and using this to read the records on the clearing member 
details (CMD) table file. If no record is found for the correspondent in question, the transaction will be sent to repair 
with an appropriate error message. If the Correspondent details were not supplied and they could not be automatically 
derived the transaction would also be sent to repair. 

If at least one channel could be used (I.E. record on the clearing member table file), the Payment-type would be set to 
'CLG* to indicate that the router is to decide the channel to be used. 
See Appendix H for FT-CORRESPONDENT processing. 
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bearing 0 ^ CIearing ,^J ianneI which **** is a member of but correspo^fe NOT a member of 

Scenario 5 was a situation whWe "Their Correspondent' was a member of the clearffchannel requested In this 
situation, Their Correspondent* is not found on the clearing member table file (Not a member of any clearing to which 
j ! S Imked )- 111 manual payment input, this situation would require the payment to use TARGET. In this case the 
details supplied are invalid and FTS will reset the channel data to space and set the Payment-type to *CLG. The' 
transaction will then be processed as if no channel details had been received. 

Scenario 7. Valid clearing type/channel correspondent is a member of clearing to which FFT is a member but 
correspondent not a member of clearing specified. 

In the following case, the 'Their correspondent is a member of a clearing to which FFT is a member, (i e record is 
found on the clearing member table file), but it is not the clearing which has been specified. In payment input this data 
is allowed and the system will indicate that TARGET is to be used. For straight throughs however, no facility will be 
given for customers to process through TARGET. FTS will ascertain if TARGET is to be used. For this situation, FTS 
will remove the channel data and process as an channel type input, (as per scenario 2 above). 

Scenario 8. Valid Clearing type/channel but FFT is not a member of the clearing specified. 
This scenario arises when a customer wishes to receive their funds through a clearing system of which FFT is not 
member. The example above indicates /RTGS/PTE (assumption is that PTE is a valid channel and that it is an RTGS 
clearing mechanism). Straight throughs will read the CMD (clearing member and preferred routing method) table and 
if no record is found the transaction needs to be sent to repair no preferred routing method was found. If a record is 
found the payment -type is set to *CLG' and the transaction will be processed further in the router. 

5.2.93 Identification when TARGET is to be used. 



5= is 

!i ! 

= - • 



Need to identify when target is to be used as extra details will be required to ensure that when the product is generated 
the required TAG information is available. To allow for efficiency, the decision whether TARGET is to be used or not 
will be made in straight throughs and payment input. If TARGET is identified, a new field FT-TARGET will be 
updated to indicate so. This field will then be used to ensure that the correct details are available/obtained and mapped 
to the outgoing message. r>f 

Decisions on when TARGET is to be used. (Assume Instruction-Type of 'LQ* indicates a Liquidity Payment) 



m 
i 


Dechkm • .«-*"...■-. 
Instruction-Type - 'LQ' <and> 
Channel has been specified. 

Note: 'LQ* with Payment-type = *CLG* is invalid 


Remarks ' *' 
Not valid as XQ* only 
available in FFT payment 
input onwards. 


2 


Instruction-Type NOT=* *LQ' <and> 

Correspondent is not a member of channel of which FFT is a member <and> 
Payment-Type = *CLG\ 

Note: Preferred payment option will be held on the channel member table (CMD) 


Obtain details whether 
PAYBANK prefers 
TARGET or corr. 
payment. 


3 


Instruction-Type NOT- 'LQ' <and> 

Correspondent is a member of channel of which FFT is a member <and> 
Payment-Type = 'CLG' 


Not a TARGET Payment 


4 


Instruction-Type NOT= 'LQ' <and> : 

Correspondent is a member of channel of which FFT is a member. <and> 
Payment-Type indicates use of a channel to which the corr. is not a member. 

Note: This facility will only be available in Payment Input, not straight throughs. 


No valid in Straight 
throughs. Set channel 
specific data to the 
clearing type and set 
payment tye to *CLG*. 
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5.2.9.4 Validation to ensure tha^Ufficient details are captured at payment i 



ta^^ffi, 



At stra.ght through* FTS nee3?!S ensure that sufficient details are available so that or!cTthe transaction gets to payment 
routing, the router will have sufficient details to choose any of the available clearing channels without having to send 
the transaction back to repair to obtain further details. If insufficient details are supplied, the transaction needs to be 
sent to repair so that the necessary details can be captured. 

Each of the clearing tasks needs to supply their data requirements so that they can be consolidated to ensure that all 

relevant details are captured in payment input 

- CHAPS EURO (CHE) 

- EBA (EBA) 

- French Clearing requirements. (TBF/SNP) 

- German Clearing (ELS/EAF) 

Validation routine will be a new CICS COBOL module to allow it to be used from COBOL or NATURAL. 
5.2,9.5 Completion modules 



FTK0014 straight though processing currently calls/links to the following programs that will require changes and or 
inclusion into the Payment routing module. 
Straight through modules affected are: 



FTK0015 



FTK0017 



FTK0023 



FTX0032 



FTK0033 



TRANSACTION COMPLETION(PIRECT PYM T) 
TRANSACTION VALIDATION ~ — 



ROUTING MODULE 



TRANSACTION COMPLETION (LOCAL CURRENCY SWIFT) 



TRANSACTION COMPLETION (ELECTRONIC BANKING) (LOCAL 
CURRENCY CCAP) 



YES 



YES 



YES 



YES 



When Straight thrus decides which status to set the payment to next it does so by accessing table TTY 
370xx^ ayment 15 3 EUFO neXt l0Cal X b ° rder StatUS fr ° m 1TY teb,C Sh ° Uld n0t be USed 1115163(3 set the status to 



5.2^0 IDR , IDR Contingency, and Marketing Approval 



111 



These applications will have to be changed as follows:- 

Sox^ 3 ^ 11 ' ^ 3 EUr ° ^ l0Cal X b ° rder St3tUS fr ° m m t3bIc Sh ° uId n0t be Used * ****** set status *> 

Also FTK0025 has hard coded 370 stage status:- 

Line 793 Checking for inactive transaction or where stage-status is less than '370' 

This needs to be changed to check where stage-status < '369'. 
Line 846 Same as above, needs to be changed to check '369\ 
Line 867 Check on '370 should be changed to '369* 
Line 871 Moving *370* for PC Contingency, should be changed to *369\ 



. CM*WWOM9trSkM-0O*U17 DOC 
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5.2.11 New Payment Routing p^^s FTK0090 

Assumption is made that all transactions that are read by the Payment Routing module will be processed through the Flow 
Control Process. To cater for this, the Router will add a new record to FT-FLOW-TRANS for all transactions that pass the 
router validation. Once a record has been added to the FT-FLOW-TRANS file, processing is effectively passed to the 
Flow Control Process and the Router has no further involvment in the payment unless it is re-routerd. 
Delay processing 

Currently transactions are delayed at product generation. This delay facility will be included at Payment Routing The 
idea is to have delay functionality at the Payment Router and Product Generation but a transaction will only ever be 
delayed at one of the queues (either at payment routing or product gen.). 

Transactions can be removed while at delay by deleting them and if need be re-entering in Payment-Input This 
fiction will be available for those transactions that are delayed at payment routing because at that stage the transaction 
will still be live. Within payment routing, the 'Live' status of the transction is removed and the will therefore not be 
able to be deleted (removed). 

Multitasking/streaming the routing module. 

It is believed that by the time transactions reach the payment router, there should not be the same volume as are 
processed by the earlier sections and the timing of the transactions reaching the router should not cause any undue 
delay. It is for this reason that no streaming will be performed on the routing process. Therefore only one router 
^ background task will be used. 



I CM*NOOi*SiTEM*~CM2aTOOC 
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PAYMENT ROUTIN 



Obtain static information that is to 
be used for all the transactions 
that are to be processed by the 
router. (E.G.: Channel details) 




Router 



1 


r 




Initialisation 






r 


Read FT-TRANS 



Risk control, I AT w in set the status to the 
correct value J^^fe router to pick up. 
Only those trfl^^Hpns that need to be 
processed by^^^Buter will have their 
status's set to awaiting routing status. 



Payment type has been set 
Either at payment input in FFT or 
by straight through because of/ 
RTGS/xxx or/NET/xxx data is 
found. 

Processing to decide if the 
channel available 




Set the channel type 
data to /RTGS/ or /NET/ 
depending on the 
payment type of the 
instruction. 
Access the channel type 
on new channel table 



Reset data to channel 
type /RTGS/ or /NETT/ 



As the channel has 
been specified, any 
special formatting 
requirements would 
have been addressed in 
straight throughs etc. 



: Send to FLOW 
: CONTROL 



Cannot change the 
channel as required 
for the liquidity 
payment. 



Set Payment Type to 'CLG' 
and stage status to 373xxx 




r 




^^PAYMENTe^r^- 
|i^RClWER#^^ 


-ii 



Send to payment 
repair 



Decision A 
Decision B 



Decision C 



Is the channel available. Check against the new Channel Table field CHANNEL- 
STATUS. If 'O' = open and available. 

Is the channel on holiday?. Use the CHANNEL-HOLIDAY-TABLE field to identify 
which holiday table needs to be read to decide if a channel is on holiday or not. 
Has a cut-off time for the channel been reached?. Obtain cut-off time details from the 
channel table field CUT-OFF-TIME. 
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5.2 J 1.1 Initialisation. 

t When the router backgro k starts up, various static details need to be obtairHPat are to be used for all 

transactions processed through the router. Details will be obtained for each clearing where the Clearing-member 
field is set to * Y* and will include: 

Clearing Type 
Clearing Controlled 
Default Processing Priority 
Channel Holiday Table 
Clearing Country Code 

Note: If a change is made to these details on the ECC record, the change will only become effective the next time 
the Router Background task starts as the Initialisation section will only be performed at the start of the router 
process before the transactions are read. 

5.2.11.2 Processing of transactions by the router. 

To cater for the facility to delay transactions at payment routing, the router will need to perform two reads to 
process all transactions that require processing. The first will read all transactions that have a stage status of 369xxx 
while the second read will process all the transactions that have been re-routed by the router module or the flow- 
control module- 
Transactions will be read by stage status of 369xxx or 373xxx. 

f]1 Transactions with stage status of 369xxx will be processed through the delay facility as the module that sets the 

i:3 stage status to 369xxx will also set the RELEASE-DATE-TIME value to allow for the delay of the transaction. 

i*« Transactions with stage status of 375xxx will be read without taking into account the RELEASE-DATE-TIME 

f'= value and will therefore NOT be delayed. 

V\ \ 

hi Keys to be used to read the transactions will be: 

i . | 

M Read 1. LIVE-STAGE-RLSE-PAY (A20) 

U TRAN-LIVE (Al) = *L* 

j]j STAGE-STATUS-MPYMTS (A6) - '369xxx* 

U RELEASE-DATE-TIME (A 13) = YYMMDDHHMMSSS 



Hi 



Read 2. DELI V-QUEUE-PA Y (A 1 2) 

PROD-DELIVER Y-IND ( A 1 ) = < 1* 

STAGE-STATUS-MPYMTS (A6) = *375xxx' 

DOE-CNTRL-SEQ (A3) 

SOURCE-IND (Al) 

TRANS-TYPE (Al) 
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Note: The sequence used l||rocess transactions by the router will not take into ^mt the urgent indicator. 




Straight Through 



Router 



Flow-Control 



Product Gen 



\ V 1 ROUTER J / 


DELAY 


f r a 

DELIV-QUEUE-PAY 


LIVE-STAGE-RLSE-PAY 


' T 

ROUTER Processing 



5.2,113 Control total updates for inactive / non-live transactions 



Currently product generation sets transactions from a live status to an inactive status and sets the inactive status 
number depending on the stage at which the transaction is in the FTS transaction flow. In particular: 

At delay product generation 
Awaiting batching 
Batched 

1 . The payment router will make 'Payment Transaction Removal Request (PTRR)* invalid. This is acheived by 
removing the 'Live' status of the transaction and means that once the router has begun processing the 
transaction it cannot be cancelled by using the PTRR facility. If the transaction is held in the bilat or DR/CR 
cap limits m Flow Control, the transaction could be sent to repair and then cancelled. 

2. The Tran-Live/ Inactive fields on FT-TRANS control amongst others things whether the PTRR facility can be 
used (see point one above). The fields also indicate at what stage a non-live transaction is at. (E G at delay 
product gen, Awaiting Batching, Batched). 

3. A new inactive stage of 'At payment router' will be maintained as the router will now also perform the same 
process as is currently performed by Product Gen with regards to inactive status of transactions. The new 
control number to be used is 07. (e.g. Control total for Transactions Awaiting Router for payments today will 
use the following identifier - CNTIPTD07). . 

4. The control total enquiry screen will be updated to report the new control total values. (FTGN900) 
See appendix K for screen changes. 
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Inactive Proces 



Transactions that are read with 
stage status of 375xxx wifl have 
FT-TRAN-LIVE value of* 1 and 
would therefore not be processed 
through the FT-CONTROL-CNT 
file. 




Set the FT-TRAN-LIVE 
indicator to space. 



1- 

u 



h 1 

hi 



Update — 
FT-CONTROL-CNT file' 

with the required 
Valups_ 



I New key ~ 'CNTIPTDOT 
I Add to OB & CR amounts 




Continue Processing 



5.Z1J.4 Transactions that are to bypass the router. 



There axe certain mstructions that need to bypass the router module as they arc not clearing instruments and therefore 
no rourtng decs.on » required as they are "CPO's" and they do not have to be monitored by flo^onrroT 

SowfoTtht re y ^ h r* e , SitU f ° n WhCre 3 Cfedit taStniCti ° n necds to 8 enerate « ° u «S0ing instruction.. To 
2 lZf?I /? P u * C faC ' hty f ° r 3 USCr ,0 m0VC 3 credit t0 the P 3 ^* P™»« so tbt the required 
™S? ^ ^ bC genWated 3t ** Cnd ° f * e flow < Product Generation). These credits need to be 

passed to the payments process as the product generation modules are only available to the payments process. 

Telex s) from the end of the crecUts process. This should alleviate the need to move these credit to the payments leg. 
^rations have requested that the existing functionality for moving credits to the payment leg be maintained These 

^Z^ZJ ^ rOUt " bC SCnt direCt ' y 10 pr ° dUCt as **y h-e a paWtype of -CTO' 

nJ™^ °f ,S , that 3 P^^'yP 6 ° f ' CPO ' will indicate a non-clearing or credit down-me^ayment-leg 

Scln ,h PrOC ! SSed - thr ° Ugh r ° U,ing 3nd fl0W COntro1 - If rcuter needs «° P"«*« a cig 8 

ZEZ r r f 3 COrres P° ndent (CMD details indicate that the Paybank/'Their Correspondent' requires payments 

a ctarS tZt* Tff ^J 0 "*' ^ "* ^ ^-'^ '° '<*<>' and paks to Flow Control^ S 

a clearing instruction although it has a Payment-Type of *CPO\ 
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2. 

3. 



5.2.11.5 Validation Rules. 

1 . Holiday date validation-TWntly both EAF and ELS are closed on German national holidays After the 

introductton of the EURO, EAF will continue to be closed on German national holidays but ELS will be open 
Other clearings are still to finalise their holiday date requirements " 
The payment router will not validate any liquidity values. The main decision from the router's point of view is 
which channel should the payment be sent to. The flow control process will validate the liquidity issues. 

t ™ St ^ ^ , CUS, ° mer ' thCn FTS WiU attem P l 10 P rocess an RTGS channel, but 

it may not be the specific RTGS channel requested by the customer. 

5.2.11. 6 Processing NOT performed by the router. 

1. Customers may want FX to go through EBA but other payments through a different channel, and they will not 
-> r?i to c« ™ * f ° n eVery transaction - FTS w *» NOT be modified to cater for this situation 

2. Swift , SSI Database. As this facility is not going to be available till the 1st or 2nd quarter of 1998, the inclusion of 
fhn ; request in the current EURO project is not possible and will not be considered in this design 

FTS does not need to maintain a history of channels tried. The reason for this information was that if a customer 
had requested ELS but because of certain factors (e.g.: ELS had crashed), we had to use TBF to affect the 
payment, we would need to have some indication that we had tried the specified channel. The conclusion reached 
from discussions was that we do not need to maintain channels tried because we do not guarantee the channel 
specified aid if we get complaints, we can obtain various details from the channel authorities themselves (eg can 
get unavailability uifo from EBA etc.). * *' 

4. May have audit details available for the flow control process, but this will not be processed by updating the stage 
m status history details on the FT-TRANS record. e 

° a U ? Uidity dC,ailS fa 11,6 Clearing channels and bilatera] limits wl *n deciding on the channel to use 

U 6. Minimum clearing volumes/values for the various channels. 

7. Any hold-ups in the channels (operations could close the channel if the queue to the channel becomes 

|1 j unmanageable) 

y 8 - No facility will be provided for a customer to set up default preferences. 

y 9. No automatic process to route transactions down a channel because anorher is busy 

*"* Jym'eT 11 " tnmSacti ° n WiJ1 DOt * taken int0 consideration when deciding on the channel to use for the 

5.2^11. 7 Channel availability. 

iJl 1. The flag on the channel record indicating whether the channel is available or not will be used to indicate if we are 

nTd^d cha ^MTais would mean that if the ABK machine was down but ELS was not, and ABK 

» £ £ ^ * 3t Aey , WOU d be available for the rest of the day, then the flag for the ELS channel would be 

, C,OSed , ° r D0 ' avalla ^)- The router will not be making use of more than one channel available indicator 
(i.e Router will not check whether Actual channel has crashed, our link to channel has crashed, TARGET 
crashed etc..) 

2. When a channel crashes, information needs to be obtained to allow OPS to make a decision as to whether they 
expect the channel to be temporarily unavailable or whether it is more permanent. For a temporary crash, the 

vS™ k >, 3g ^ be . k ^ t V 3 ' Y ' meaniDS *»* channel is sti » avaiIaWe but Debit/Credit cap limit 
validation can be changed to hold these channel payments until the channel becomes available after which the 
limit can be changed back to allow the payments to be sent to Product Generation and out to the channel 

3. If an Instructions is to be sent through TARGET, the router will not have any validation in place to validate that 
the destination clearing is available or not. 

4 ' ^r^T T he f ? C T" er D ° ChanneI is availab,e ' (e * ^ one channel ( e -g - ELS) can be used to 
get to dM ■ Pavbank and this channel is unavailable, then the transaction will be sent to repair. A decision could then 
be made to identify that it was our link to the channel (E.G.: ABK) that was down and a new channel can be 
specified to get to the paybank through TARGET (assuming TARGET was available)) 

Cut-off tome processing requirements. Need to validate cut-off time parameters for any specific cut-off processing 



5. 
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5.2.11.8 Channel priority 



Priority for processing channel info will be maintained manually. Each paybank that has a specific priority required for 
deciding on the channel to use would need to be updated manually. A default priority list will be maintained for those 
paybanks that do not have specific priorities set. The default processing priorities will be held on the ECC table records. 



5.2.11.9 l CLG* processing 

If the customer has not specified the clearing channel to be used, the Router will process the transaction through a 
decision making process to attempt to automatically derive a channel to be used. 

Clearing channel supplied but not a channel that FFT is a member of. 

If the incoming TAG72 details contain channel specific details and FFT is NOT a member of the clearing channel 
specified, these instuxctions will be processed as 'CLG* payments with only the clering channel type details used by the 
router. 
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CLG Proc 



NO channel specified on 

incoming message. 
Payment Type = 'CLG' 



A- 

recoros froi 



Use the p^HMletails for the transaction to 
read the recoros from the FTS-TABLES file. 
Details returned will be: 
PAY BANK (A 12) 
CHANNEL (A3) 
PRIORITY (n2) 

TARGET-THEtR-CLEARING (A3) 



Included should be code to 
exclude non RTGS or 
NETT clearings if customer 
specified instruction to be 
processed through /RTGS/ 
or /NETT/ 



Obtain list of available 
clearing channel 
options. 



NO 




Channel Priority 
EAF 01 
ELS 02 
SNP 03 
EBA 04 



FTS-TABLES 
ID = CMD (Clearing 
Member details) 



Example 1 



Example 3- 
1 — Example 2- 









Channel 


Priority 


Destination clearing 




TGT 


01 


PTE 



Channel Priority Destination clearing 
COR 01 PTE 



Correspondent (NO)- 



Sort available clearings 
into priority order 



Target (YES) 



Obtain list of valid 
RTGS clearings. Default 
priorities for CHASE. 



Validate that channel 
can be used. 




Decide on channel 
to be used to 
transfer funds. 



Payment-type set to *CPO\ 
Ensure our correspondent details can 
be derived. This is done by reading 
the channel table records for the 
destination clearing ID. The record 
holds our-correspondent SWIFT 
address. 



NO- 




Set payment type to 
channel. Continue. 



Channel specific 
formatting* 
requirements. 



Send to FLOW 
CONTROL 
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» use. 



5.2.11.10^ Decision rules for choosing clearing channel to 

If more than one channel cb^^used, the router will need to decide on which ch; 

Decide an channel to 



to be used. 





List of 
channels that 
could be used 
in priority 

order. 




Decide on channel to be used 
when more than one possible. 




V 




Change priority if required, 
(e.g. FTS internal 
requirements minimum 
volumes etc.). 


p> 




Rules to decide if 
channel can be used? 



YES 





ERROR as no channel 


l = : 1 


can be used. 




fij 




r 


r 


Send to PAYMENT 






REPAIR 






Channel passes all rules and can 

therefore be used. 
Set Payment-type to the required 
channel. 



SEND to FLOW- 
CONTROL 



5.2.11 .1 1 Special clearing channel formatting. 

fo™^!!! 31 inStrUCti ° n Was ' CLG ' or * e P^nt type has been changed by the router or Flow Control special 
formamng reqmrements wUl need to be included to cater for the channel that has been chosen by the router 
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Special Fnrr^ tin 



Special Channel specific 
formatting requirements. 



By this sWf^ the clearing 
channel that is to be used 
ahs been decide on and the 
Payment-type has been 
changed to indicate this. 



fMENT-TYPt 
'ELS' or *EAF 



I'M E NT-TYPE 
JTBF or 'SNP' 



r*ME NT-TYPE 
'EBA' 



fMENT-TYPt 
'CHE* 



fMENT-TYPE 
•CPO' 



YES 
> ► 




FORMATTING FOR 










EAF and ELS 










VES 
> > 




FORMATTING FOR 










SNP and TBF 










YES 




FORMATTING FOR 






1 


EBA 







YES 
> > 




FORMATTING FOR 










CHE 







YES 
> ► 




FORMATTING FOR 










CPO 







ERROR ??????? 
This should not happen'! 
Payment repair? 



Continue 



5.2.11.12 Passing control to flow-controL 

Once a channel has been identified (either by the router or if the channel has been specified by the customer, the 
router will need to pass control to the flow-control process. This is achieved by adding a record to the new FT- 
FLOW-TRANS database that will be used by the flow-control modules to process the liquidity validation. The flow 
control process will then perform the validation necessary against these records. 

The process of passing control to the flow control module requires that the FT-TRANS record be updated to indicate 
that the transaction has been sent to flow control. This will be done by changing the stage status to 374xxx. This will 
effectively stop FTS processing this transaction while the flow control process is being run. 
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, Store devils to new FT-FLOW-TRANS file that will be used by the flow control module as follows. 



■i.-^i field ;.• * 




BRANCH 


e.g. 616 


STATUS 


Awaiting Bilat Check 


HELD-IND 


'N' 


TIME-CREATE 


Time created on this Dbase 


BILAT-ID 


The swift address of "Their correspondent" bank that we are sending the payment to. 


OtlAiNJN tL 


r 1-iKAiNb.r 1-rA iMhiM-1 Yrb or aWlH addressoi (Jur Correspondent it the 
payment-type is l CPO' (i.e. Correspondent transfer). 


URGENT-IND 


FT-TRANS.FT-URGENT 


AMOUNT 


FT-TRANS.CR-AMT 


FTS-TRAN-REF 


FT-TRANS-REF 



Correspondent processing 

If the payment is to be processed through *Our Correspondent* because we are unable to use one FFT*s clearing 
channels, the payment type would have been set to *CPO\ When the FT-FLOW-CONTROL file is updated with the 
new record, the channel details (on FT-FLOW-CONTROL) will be populated with 'Our Correspondent* details. This 
will allow for the monitoring of payments made through each of *Our Correspondent's*. 



5.2.11 A3 PC Contingency update. 



During the passing control to the flow-control process, the router will also update the PC-Contingency data. This will 
be the only extra update to the contingency details as a result of the new routing/flow-control process. This update 
will be performed as the control is passed to the flow modules as it is at this stage that the channel that is to be used 
has been identified. 



Field" 




FTK0049-FTS-TRANREF 


FT-TRANS-REF 


FTK0049-STAGE-VALUE 


369* 


FTK0049-TRAN-LIVE 


Space 


FTK0049-RCODE 


SPACES 


FTK0049-BRANCH 


<BRANCH e.g. 616> 


FTK0049-TRAN-INACTIVE 


07 



NB if a new Contingency system is in place by 1/1/99, OPS require it to take into account the Urgent flag. 



On i ii Mi cmmtoowTT&^ocmmr ooc 
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5.2.12 Bilat/Channel Flow Conj^Ier FTK0091 
5.2.12.1 Introduction 



This new background task will monitor the Bilateral limits within the clearing systems. It will maintain the total number 
and amount of payments sent to each Bilat today. If a payment would put the totals over the agreed limit for that bilat 
then this program will put the payment to a held status and not let it go out of FTS. 

The process will fed payments by the Payment router. The Router will add them to a new database file FT-FLOW 
TRANS with a status of 'Awaiting Bilat check'. The Bilat process will seach for records with this status. 

First thing in the morning it will be turned on by Operations and will process all outstanding transactions. 

This process will be streamed by branch. Within 616 it will also be streamed by Clearing group. Clearing group is a 
group of payment types as defined on the CLG table. There will be one background task for each clearing group as 
defined on the BGD table. Note that as correspondent channels will have payment type CPO they will be processed 
under one background task i.e they cannot be split. 

5.2.12.2 Read access 

It will read, one by one, all transactions currently awaiting this check on FT-FLOW-TRANS It will read the 
transactions in order of Urgent first, then non urgent, and within this smallest first. It will read held transactions as well 
as new ones and will make no distinction between them. 

This ensures that all urgents for a particular channel are processed first. It also ensures that the credit limit is taken up by 
lots of small payments rather than a few large ones. This means that more payments get out the door and if we have a 
contingency situation there will be less payments requiring manual processing. 

!■* urgent on'eT" ^ paymentS f ° r 3 cbanDcl "* reIeased fu " st and s ° Wt me Debit controller before non 

1^ To read in the correct order it will use the BILAT key:- 

!ij 

BRANCH from BGD table record 

ijl STATUS set to Awaiting Bilat 

CLEARING- GROUP from BGD table record 

133 URGENT-IND set to zero 

PAYMENT-TYPE set to spaces 

BELAT-ID set to spaces 

AMOUNT set to zero 

To have just one read need status before clearing group. Note that records are not read in channel order but this does not 
affect static data reads as this is the Bilat 

5.2.72.3 For each record read do the following :- 

On change of Bilat or Channel (and on first time in) read the appropriate Limit record from FT-FLOW-CONTROL with 
key of BILAT-ID and CHANNEL from the FT-FLOW-TRANS record. 

If this program cannot find a limit record on FT-FLOW-CONTROL for the bilatfchannel being processed it will do the 
processing outlined in the Requirements section 4.0. 



Us 
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If the COOTROL-IND on this i^rd is set to N (No control required) just update the ba^ce, the number released, and 
the amount released. Then rel d^B^ payment to the Debit cap controller. Do this for J^^ayment within this 
bilat/channel. Otherwise do tr^JJ^wing:- ^^^F 



For each record within that Bilat or Channel, check that the amount would not put the balance over the limit on the 
FT-FLOW-CONTROL record. If it would then set the record to held and read the next one. If it wouldnt then update 
the balance and release the payment to the debit Cap controller. 

On finding that an urgent payment needs to be held the process will set all subsequent payments in that Bilat/channel 
to held also. This means that a smaller non urgent will be held even though it could in theory be released. This is to 
ensure that small non urgent payments do not use up all available credit and so continually stop urgent payments 
from being released. 

As there could be a lot of Channel/Bilat combinations within Urgent remember this by updating a BILAT-HOLD- 
IND on the FT-FLOW-CONTROL record for that Bilat/Channel. Will need to set this indicator back to *N* once 
all non urgent payments for this bilat/channel have been processed. Could do this by detecting change of key on 
non urgent payments. Or by making BILAT-HOLD-IND a descriptor and reseting all records at once at the end of 
processing(more complicated because of streaming). 



12.4 Final processing 

Once all outstanding payments have been processed it will go to sleep for a set period (eg 5 minutes). After the set 
period it will wake up and look for any more outstanding records. It will also reread any payments currently held and 
recheck them (just in case a credit arrived that increased the balance while it was asleep). Credits are added to the 
balance by a separate process described later. 



13 Clearing Debit Cap flow controller FTK0092 

This process will work in the same way as the Bilat check above except that :- 

1) It will be looking for transactions with a status of 'Awaiting Debit Cap check* but will need to read in a different order 
(urgent trans within Payment type) 

It will will use DEBIT-CAP key:- 

BRANCH set to 6 1 6 (or JPMorgan) 

STATUS set to Awaiting Debit Cap 

CLEARING- GROUP from BGD table record 

CHANNEL set to spaces (must be channel and not Payment type) 

URGENT-IND set to zero 

AMOUNT set to zero 

2) The appropriate Limit record will have table key of channel, and Bilat id = XXXXXXXX 

3) This process will also be streamed by branch and Clearing group. 

4) It will not update successful transactions to the status of 'Awaiting debit Cap check' but instead will 

- delete the record from FT-FLOW-CONTROL - Should this be FT-FL O W-TRANS? 

- update the payments FT-TRANS record to the stage status of 373xxx. It will find this record by using the ISN stored 
on FT-FLOW-TRANS 

5) It will check that the amount of each transaction is not above a maximum set for the channel, (for EBA this is 75 % of 
Debit Cap). If it is the transaction will be held. 

The limit will be held as an amount rather than as a percentage. The check will be done as part of the Debit Cap 
controller process (even though payments held in this way would already have gone through the Bilat and Agg Bilat 
controllers and so will have used up some credit in those balances). 
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6) If the controller cannot find a limit record on FT-FLOW-CONTROL for the payments Channel, it will release jhe 
payment as if it had passed 2j|Kbeck, and it will update the usual totals. (Because <^flfcjrocessing in the Bilat 
controller these payments v^^Hier only be for channels that dont need checking dH^Payments have been released 
by Ops on purpose). 

NB Payments held due to this check will not be highlighted or marked in anyway. Their large amount will be the only 
way to distinguish them from payments failing the debit cap check. NB also that their large amount will ensure that 
they appear on the online screens at the end of all other payments. 



5.2.14 Validation of payment data - New module FTK0093 

In the current product Generation transactions with Stage Status 370xxx go through various validation. Transactions with 
Stage Status 375xxx do not, because they used to be 370xxx and so have already been validated. 

As Euro clearing products will be set to 375 before they reach Product Generation they would potentially miss this 
validation. Hence the validation will be copied and included at the end of Flow Control. It cannot be put before the held 
queues because one of the checks is ensuring that the DOE is still open. 

Transactions leaving the Online flow control and going direct to product generation will also have to be validated in this 
way. 

Hence this validation will be written as a module which can then be called by the Debit cap controller and the online 
screens. 

y1 The validation required will be : - 

l- h Account status 

DOE closure 
Tli Product status integrity 

I i J Held product indicators ?? or is this x border only ? 

b j Also must set PROD-DE LIVER Y-IND to I so prod gen will read these 375 records. 



5.2*15 FT4710- Start/stop Routing and Flow Control Background Tasks 

| r ;= A new application will have to be set up for the Start and stop of the Routing and Flow Control Background tasks. 

Ul This will be a clone of FT3 55 6/FT3493/FT3489 which are other application background task start ups. 

VO A new table entry will also have to be generated on the STF table for the new application id, this will be passed 
as a parameter to the subprogram FT3499 which then kicks off the actual background task ,or stops it depending 
on the request from the user. New table entries will also be required on BGD table for all new background tasks. 
No program changes are required to any existing programs. 

Program FT3469 displays the current status of all the FTS background tasks. If the new background tasks are 
currently running they will automatically be picked up by this program. 



5.2.16 CICS Control of Flow Control programs 

These new background tasks will be controlled in a similar way to the other FTS tasks like Fl 1 A. They will be streamed 
by branch but also they can be streamed within branch. 

They will be designed such that it will be possible to stream them by individual Payment type (EBA, ELS, EAF, CHE, 
SNP, TBF, CPO), or by grouping up any of these (eg one clone for French clearing , one for DEM, etc or even one clone 
for everything). NB Payment type is different to CHANNEL as each correspondent bank is a different channel but only 
one payment type - CPO. 
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How they ar© streamed will be contolled by tables, in a similar manner to the VMT and B^D tables. Because of the 
requirements to have more than^^Htical time period per channel the second data line^^^BGD table will be used to 
store up to 5 more critical timesj^^PBtal). There are seven clearing channels in Correspo^BK banking is counted as one. 
Hence if all seven require different Critical times then at least two clones will be required. 

Payment routing will set up a field on FT-FLOW-TRANS called CLEARING. The value of this field will be determined 
by a new table 'CLG* that Payment Routing will access. This table will govern the way in which the clearings are grouped 
(and therefore streamed). 

In the example below it has been agreed to stream Flow Control by country clearing mechanism IE French clearing, DEM 
Clearing etc 

TABLE -ID: CLG DESC : PAYMENT -TYPE 

CLEARING GROUP 

SEL VER TABLE-KEY TABLE-DATA (FIRST 50 CHARACTERS) 



Y EAF DEM 

Y ELS DEM 

Y TBF FRF 

Y SNP FRF 



Each Flow Control clone will only read records on FT-FLOW-TRANS that have a certain value of STATUS and 
CLEARING. The value of CLEARING that it will look for is obtained from a new table TLW\ 

In the example below F91 A will read any record with CLEARING equal to DEM. This means all Deutsche clearing types 
jli ELS and EAF. 

TABLE -ID: BGD DESC: CICS TRAN ID 
j^l DELAY | HELD RECORD j CRITICAL TIME START j 

H CRITICAL TIME END [ HELD RECORD DELAY | B KG TRAN DATA 

"• == SEL VER TABLE-KEY TABLE-DATA (FIRST 50 CHARACTERS) 



0500 0003 0001 0001 0000 NF90BABND002 DEM616 Y 
0502 0002 0003 0003 0004 0504 0005 0005 0006 0006 

New records will be required on the QSE table to control the error processing. Queue Status Enquiry currently uses the 
:*f Q SE to out wni ch TSQ to look at to get the error description, i.e. - When enquiry looks at TSQ FTABNDT1 
m and finds that position 032 is flagged, it then goes to table record 'QSE' and gets the name of the TSQ with the error 

description - F90AABND. See section on tables later. 

5.2.17 Error processing in the Flow Control programs 

If a system error occurs during the processing in the Flow control and payment routing background tasks then the CICS 
transactions F88A and F99A must be abended and a message written to the CICS TS queue 'F88AABND* and the master 
TS abend queue record FTABNDTl . The transaction record updates must be backed out and the stop task indicator on 
the BGD control record is set to prevent further runs of this transaction. 

The error will then show up on FTS Queue Status Enquiry. 

5.2.18 Online Flow Control 

Online function for enquiring and controlling payments held at the various stages of liquidity checks. Access to this 
functionality will be via either one of two applications, Enquiry or Update. Users with Enquiry access will only be able 
to enquire on the Held payments in Flow Control. Users with Update access will be 3ble to monitor and control payments 
in Flow Control. All Held records on FT-FLOW-TRANS will be available for Enquiry and/or Update. 
See Appendix I for Screen Flows Diagram and all screen layouts.. 
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5.2. 18.1 Main Summary Screen. 

The first screen will be the mai^Plrimary screen and will be accessed by Superdescripl|^r(m section 53) which will 
display the number of transactions and the amounts for payments held at each stage of the liquidity checks, Bi-lats and 
Debit Cap for each channel/correspondent. Pressing ENTER will refresh the screen at any time. 



On entering 'V to view options available the following window will be displayed. 



Options 

1 - Reroute Channel 

2 - Display all Urgent Payments by 

Status 

3 - Display all Paybanks by Channel 
Enter Option :X 



These options are described below. 



5.2.18,2 Option 1 - Reroute. 

If this option is chosen another window will be displayed which will give the user the chance to specify a new channel 
to reroute to, or leave blank and let the routing module decide. 



"Reroute Window 



Enter channel to reroute to 

or leave blank for Routing module 

to decide 

:XXXXXXXXXXX 



If a channel has been specified the program will read through all the payments by Superdescriptor 1 (section 5.3. and 
for each one do a lookup on the FT-FLOW-CONTROL file to check that a bilateral agreement exists for that paybank 
and channel. If no bi-lat agreement exists then the payment will stay in Flow Control and not be rerouted. If a bilat 
agreement does exist then the payment will be routed back to the routing module where it will be formatted for the new 
channel. 

If no channel has been specified, the selected payment(s) will be routed back to the Routing module with a payment 
type of *CLG' and the routing module will decide on the appropriate channel. 

The stage status on FT-TRANS must be set back to 370XXX, so that the routing module will pick these payments up 
and any urgent payments will be reset to non-urgent. 
Users will have to confirm their actions by pressing PF2. 



5.2.18.3 Option 2 - Urgent Payments for Channel 

This option will access the records by Superdescriptor 2 (section 5.3.) and display all urgent payments for the chosen 
channel in order of Status (either 'B* or 'D*) then paybank then value i.e. the lowest value fast. The time displayed 
will be the time elapsed since the payment first entered Flow Control. The screen will be refreshed each time ENTER 
is pressed. 

When entering a '?' to display the options a window will appear with the available options. These are described in the 
section below on "Individual payment options". 



■mmrooc 
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5.2.18.4 'Option 3 - Display all Pranks for Channel 

When selected this option w^^Hss the records by Superdescriptor 3 (section 5.3) a^^H^lay for each paybank, the 
number of transactions and tr^^mounts for each status i.e . Held Bilat and Held Debit^^It will also provide the 
functionality to be able to toggle left and right to see Bilat and Debit Cap excess positions and limits. This will allow 
the user to guage how much the Bilat and Debit Cap positions will go to if the Held bilats are released. 



On entering a *?* to view available options a window is displayed as below: 



Options 

1 - Reroute Paybank 

2 - Display Payments for Paybank 

3 - Release Paybank Payments to 

Product Generation 

Enter Option: X 



iJ J 



1 Reroute. 

Same as option 1 - reroute from main menu. 

2 Display Paybank Payments by Status. 

On selecting a paybank and entering a status a screen will display all payments for that paybank/status. 
e.g. DEUTDEFF/HELD BILAT. 

The payments will be displayed in order of urgency then amount of transaction (smallest first). The fields displayed 
will be Transaction Ref no, amount, urgent ind, time(being time elapsed since first being held). Also the net balance 
for that paybank/channel will be displayed. These records will be accessed via Superdescriptor 4 (as detailed in 
section 5.3). 



FTS PAYBANK ENQUIRY/ CONTROL KH : MM DD/MM/YY 

PAYBANK XXXXXXXXXXX SUMMARY SCREEN 
STATUS : HELD AT BILAT 

NET BALANCE FOR PAYBANK IS 999,999,999,999-99 



Page 1 



TRANS. REP 


URGENT 


AMOUNT 




TIME 




88634S67 


Y 


7,367,439 


00 


00 


05 


.31 


99996667 


Y 


534 , 222. 456 


00 


00 


07 


-45 


23987653 


Y 


725, 765, 776 


00 


00 


07 


57 


84849593 


N 


1, 543 , 098 


00 


00 


05 


03 


55434376 


N 


220, 773, 452 


OC 


00 


03 


21 


01234567 


N 


398, 543, 098 


00 


00 


10 


09 


86834567 


N 


721, 76S, 776 


00 


00 


30 


32 


99996667 


N 


898,222, 456 


00 


00 


14 


03 


23987653 


N 


899,367,439 


00 


00 


IS 


40 


84849593 


N 


901, 999, 999 


00 


oo 


03 


59 


23987653 


N 


934,367,439 


00 


00 


15 


40 


84849593 


N 


999, 999, 999 


00 


00 


03 


59 



Enter *?' to display Options 

PF7 page Back, PF9 Page Forward, PF3 Back, PF5 Restart, PF12 Main Menu 



On entering *?* a window will be displayed with the available options. 
These are described in Section 5.1.10.7 
Other functions available from this screen are : 

PF7 Page Back 

PF8 Page Forward 

PF5 Restart 

PF3 Back to Paybank Summary Screen 
PF 12 Main Menu 



3 Release Payments to Product Generation. 
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This option allows the use^^^hoose all payments for a paybank and release the rn^^k Pro duct 

Generation bypassing the^^Hiing liquidity checks. All the relevant Flow Contrd^^Bbces will be updated. Should 

be able to choose several pa^anks at a time and they should all be processed 

simultaneously 



5.2.18.5 Non-Urgent Payments for Chosen Channel 



This screen displays non-urgent payments for a channel and status and is displayed in order of amount 
(smallest first). It is accessed from the Urgent Payments for Channel screen. The access key to retain these 
records is Superdescriptor 2 (section 5.3) with the urgent-ind set to space. 

5.2.18.6 Individual Payment Options. 

These individual payment options apply to all screens where individual payments are displayed. Window displayed as 
below: 



Options 

1 - Reroute 

2 - Display Payment 

3 - Cancel Payment 

4 - Change Priority 

5 - Send to Repair 

6 - Release to Prod Gen 

Enter Option: X 



Option 1 

Same as option 1 - reroute from main menu- 



Option 2 

When this option is entered next to a payment, the controlling program will go off and fetch the actual first screen 
of Transaction data, (FTGN934) on the FTS Transaction Enquiry function. The Transaction Ref no. will be passed 
to it. 

On exiting from the Transaction enquiry, control should be passed back to the screen from where the enquiry was 
first made. 

Option 3 

When cancelling a payment, the payment will actually be sent back to repair. In doing this, Blotter will be reversed 
and IDR will be backed out, stage status will be set to 320003 and the message will also be sent back with the 
payment in the Notes field instrucing the operator to cancel the payment.The appropriate Flow control balances on 
FT-FLOW-LIMITS would be updated. 

Option 4 

A payment's priority can be changed to either move it up the queue so that it gets released to Product Generation 
quicker or can be moved from urgent to non-urgent. 

Option 5 

When a payment is sent to Repair the stage status would be set to 323003 'Blotted Awaiting Completion'. Blotter 
would be reversed causing the IDR to be backed out and FT-FLOW-CONTROL would be backed out accordingly. 
A new message would be required to reflect why this message has come back to Repair. Also CNTIPTO07 control 
totals would be backed out. 



irooc 
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Optioif 6 



On forcing a payment thrqj^^^ Product Generation, therefore bypassing other Iiq[^^Bchecks, the balances on the 
FT-FLOW-LIMITS file sh^Ple updated. The stage status would be set to 373X3^PRhat Prod Gen would pick it 



5.2.19 FT4700 - Start of day reset of flow control balances 

A new batch program will reset all the Flow control balances to zero. It will run during the night while the FTS online 
system is unavailable. 

It will read all records on FT-FLOW-CONTROL sequentially. On every record it will reset the following 
Current balance 

Number of payments held due to this check 
Total amount of all payments held 
No of Payments released 
Amount of Payments released 
No of Confirmed Credits received 
Amount of Confirmed Credits received 
HELD-IND - reset to 'N* 

The two limit fields will not be updated. 



5j&20 FT4703 - Overnight deletion of FT-FLOW-TRANS 

uJ This will be done as an overnight process once a week. To reduce the impact of these records on the efficiency of the cics 
!** tasks they will have their superdescriptors set to spaces so that Adabas indexes are are small as possible. 

TU A new batch program will delete all records on FT-FLOW-TRANS and feed them to the Foxpro process? 

(The Debit cap flow controller could delete records but it was felt that it would be safer to keep them for a while). 

FTUN038 - End Of Day processing 

This program needs to be changed to look for transactions still in the Flow Control process. These transactions will be 
inactive and so the current access on superdescriptor TRANS-STAGE-PA Y:- 

TRAN-LIVE =X t or'P' 
DOE-CONTRL-SEQ = Users DOE 

STAGE-STATUS-MPYMTS = all values 
DB-AMT-COMP = all values 

will not pick them up (TRAN-LIVE = space). Instead have a sceond access using DELIV-QUEUE-PAY> 

PROD-DELIVERY-IND = 1 
STAGE-STATUS-MPYMTS = 373 to 374 
DOE-CNTRL-SEQ = users DOE 

SOURCE-IND = all values 

TRANS-TYPE = all values 



'DOC 
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5.2.22 FT4715 - Online update^AFIow Control limit data 



A new online application will be provided that will allow the users to maintain the Flow control limits on FT-FLOW- 
CONTROL. The liquidity limits may need to be adjusted at very short notice. It is felt that using GPPM would be too 
slow as it requires verification by a second person. Hence a new online application is needed for this. 

The following fields will be updateable and all other fields will not be. 

BILAT-ID 
CHANNEL 

CONTROL-IND (Only for specific Channel/Bilat records) 

MAX-AMT 

LIMIT 

The function will comprise of an initial screen to accept the channel/bilat id. The minimum requirement at this stage is 
the entry of a channel. This will display a summary of all bilats for the entered channel, from which the user may select a 
channel/bilat id for maintenance. The summary screen will only display the fields mentioned above (except for 
CONTROL-IND). 

If both fields are entered on the first screen, the program will find the corresponding record for maintenance, and will 
display the details as in screen 3. If no data can be found for the entered id, the program will assume that a new flow 
control record is to be created. A check should be made that a Debit Cap limit exists for the channel entered. If not, the 
user should be prompted to create one and not be allowed to progress any further until this has been done. 

If a channel is to be created, the bilat id should be all *X\ and the channel should be checked against the channel table in 
TABLES-FTS. If no channel exists on the the channel table in TABLES-FTS, an error should be returned to inform the 
user of this situation and not allowed to procede any further with the creation. This entry can be created via a separate 
program. 

The Bilat id entered should be validated (if not all *X's) by extracting the first six characters, and using them to scan for 
the first record that matches on the SWIFT-ADDRESS file. 

The details in red on the screens below show the fields that are available for data entry. Other details, on screen three for 
example, are displayed for information purposes only. 

Care is needed when maintaining an existing control record, to ensure that the record is only locked for update when the 
user has confirmed that the changes made on screen 3 are correct and have been acknowledged via PF2. This will 
rrimimize the disruption to processes maintaining the balance and flow control totals on the record. 

The current balance and number of payments will not be updatable by any online screens. 

Standard Chase PF key functions will allow for navigation to and from the different screen formats, and choice of action 
on the data. 

This program will require another superdescriptor for the FT-FLO W-CONROL file of BRANCH/CHANNEL/BILAT- 
TD. See appendix C for screen layouts. 



5.2.23 Product Generation 
Changes for 370 to 375 

Prod generation itself will have to be changed to do some processing for 375 that it only does for 370 :- 
Setting of Held product indicators (or is this x border only ) 

Reduce control total for TRAN-INACTIVE = 07 and increase for 01 for transactions coming from Flow Control 
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C Ranges for CLGs 

Transactions with payment typj^^B will have stage status of 370003. These will be re^^^F08C. 

Validation for CPOs in FTKOO^^Rtion 2.2.5.8 in the spec) will have to be done for oBk as well. 
Any processing for 370s and payment types EAF etc may need changing to include CLGs also. 



Volumes 

The second read of prod gen is currently inefficient. All clones read all transactions at 375 and each clone will then reject 
those transactions it doesnt need. For Euro we will potentially be increasing the number of transactions read via 375. 
This may cause problems with the response time of these tasks. 

Ideally this processing should be redesigned such that each clone only reads its own 375s (eg EAF/ELS clone F08B 
should only read ELS/EAF transactions). However, this would be a reasonably large amount of work. Due to the time 
scales of the Euro project it was felt that this is not an essential change and can be left for a later date (or maybe never if 
response times turn out to be ok in user test/production ). 

Control totals 

For 375s if tran 07(euro only) t 07 and add to 01. 
5.2.24 Acknowledgement processing 

Initially when a Euro payment comes into FTS a wash account will be credited in Payment Input/Straight Thxoughs. 
Only when we know which clearing the payment is going to go through will we be able to get the correct nostro 
account to be credited. 

This nostro account number will be held on a new TABLES-FTS file called ECC (Euro Clearing Channel).When an 
acknowledgement has come back fom the clearing, the ECC file will be accessed by the payment-type on FT-TRANS 
and the nostro account will be held here. 
O The CR-ACC-NO on FT-TRANS will then be updated with the nostro account from ECC for that clearing at the same 
time as the other fields on FT-TRANS are being updated. 

5.2J25 Accounting feed generation 

!" ; Currently, the account entry feed jobs (PJFA020, PJEA020 etc.) have a hard coded nostro account number 

in the JCL which is passed to the program FT3594 for use in deteiTnining which items are going to be bulked. 
r ~ The hard-coded nostro account number will change but only in PJFA020 which is the Frankfurt account entry 
* feed job. The items that are bulked at the moment are for payment types EAF, ELS and EAC and it is envisaged 

that this will not change for Euro. 
1 There are no other changes envisaged at this time to FT3594, but if JP Morgan change their accounting procedures 
i- 4 we may have to hard code the Euro currency code into FT3594 to allow for a Euro entry on the DDA. 

is s 

5.226 FTS Payments Queue Status Enquiry 

This will be changed to show the new Payment routing and Flow Control status's. Also the screen for EFT branch will 
vary slightly from the screen for all the other branches. 

For FFT the changes will be : - 

Merge At Delay status with new Delay status for awaiting payment routing. 
Merge all 4 prod gen lines into one summary. 

Then use 2 of the 4 spare lines to have one line for payrouting and one line for Flow control 
Have PFKEY to go to a screen with a breakdown of :- 

4 prod gen lines, 2 Flow Control lines and 2 At Delay lines. 
Have pfkey to toggle to the online flow control screens 
Dont need PF3 and PF12 as the same thing! So remove PF12 

See appendix E for screen layouts . 

For all non FFT branches 

Keep as is. (If it is decided later that new layout is required for JP Morgan, will have to do more code changes then ). 



i bf: C.'JMMDOW5vm^-«0dl2t70OC 
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5.2.27 FTS Transaction enquiry >q 

This will be changed to disp new FT-TRANS fields. Where 7 Also changed t^Blck to online flow control if 

was called from there . 

5.2.28 FTGN900 - Today's control totals enquiry module 



The control total enquiry screen will be updated to report the new control total values fro payment routine That is to 
reflect the new TRAN-INACTIVE value of 07. 
See appendix K for screen changes. 

The enquiry module that displays the control total values will need to be modified to include the new control totals for 
the awaiting payment routing status. ( CNTIPTD07). 

INPUT TOTALS " " COUNT FT- CONTROL -KBY " " " 

BROUGHT FORWARD FROM PREV DAYS 11 - CNTLPBF 

RECEIVED VIA T'SLIP/RPI INSTRUCTIONS. 13 - C2TTRCVDT 

RECEIVED VIA SWIFT (INCLUDES FTPC) 574 8 - CNTRCVDR 

RECEIVED VIA MTS . 654 _ CNTRCVDL 

RECEIVED VIA MULTICASH i$ _ CNTRCVDU 

RECEIVED FROM OTHER CHASE SYSTEMS 53 0 - CNTRCVDK 

MANUALLY INPUT 336 _ CNTRCVDP 



TOTAL 73 08 

TRANSACTION TOTALS COUNT 

CURRENTLY ACTIVE 6819 

AT PRODUCT GENERATION 310 

REMOVED/ CANCELLED 27 

AWAITING BATCHING * 22 

BATCHED 130 

TOTAL 7308 



- CNTIPTD01 

- CNTIPTD02/03/04/05 

- CNTIPTD06 

- CNTIPTV09 



Current DD values used: 
07 - at router 

01 - At product Generation 

02 - Removed / Cancelled 

03 - Removed / Cancelled 

04 - Removed / Cancelled 

05 - Removed / Cancelled 

06 - Awaiting Batching 
09 - Batched 



FT-CONTROL records updated in a number of places. 



Taking CNTIPTD01 record currently accessed by: 



■ Nafuraf ■ 


Oetails: , • . 


FTGN900 


Control totals display. 


FTU2029 


Instrument serial number input update 


FT3066 


SwifVtelex direct out - backout program to move transactions stuck in the new 
swift/telex direct out stages into the awaiting batching Stage 


FT3416 


FTS product generation - dm clearing - eod confirm 


FT3425 


FTS product generation - dm contingency processing 


FT4403 


Lira end of day processing 


FT3422 


Accounting extract ft-trans update 


Cabot - ■ * J. ■ ■ 




FTK0008 


Product Gen 


FTK0058 


Product Acknowledgement processing task. 
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The modules will need to be updated to backout values from the new control total stageiCNTIPTD07) before adding the 
CNTIPTD01 stage values. Se^Skles that update CNTIPTD06 record for backout P^^fc 
Processing requirements for ufj^g the FT-CONTROL-CNT records see Appendix l!^^ 

5.2.29 Contingency 



Payments that have at some stage of their flow to the clearing bank been rejected or not actually made it to the clearing 
will be made available for contingency processing. This option currently exists within FTS for DM Clearing 
Contingency. 

There will be two new options within FTS for CHAPS Euro Clearing Contingency and French Contingency (as below). 
The new options will be based on and will follow the same processing as DM Clearing Contingency. 

5.2.29.1 German Clearing. 



Currently payments that have a stage-status of 375001, 375002, 37501 1, 375014 and 375015 and are a payment type 
of 4 EAJ\ 4 ELS* or l EAC* are available for DM contingency processing. These statues mean that either the payment 
has been rejected at the clearing, has had an error at Product Generation, is awaiting an acknowledgement or is 
waiting to be sent at Product Generation. After Product Generation, the transaction is flagged as inactive so is not 
retrievable for cancelling. Therefore the contingency process is essential so that the payments can be sent back to 
Payment Input for repair and put through processing again. 

For options I and 2, payments at stage status of 375015 (Rejected by LZB) are available, and for options 3 and 4 
statuses 375001, 375002, 37501 1 and 375014 will be available. 

The new fourth option will be added to the screen to enable a payment to be sent back to Payment Routing. 
See Appendix F for screen layouts. 

5^29.2 FT4720 - CHAPS Euro Clearing. 

M Payments available for CHAPS Euro contingency will be of payment types *CHE' and 4 EBA* and at stage statuses of 

!1 j 375001, 375002 and 37501 1. These are either awaiting acknowledgements, waiting to be sent out, error' d at Product 

y j Generation, or Nack'd . 

hj 

),h If we are going to have a specific stage status for rejection of the payment at CHE or EBA (as for DM) then we can 
provide options 1 and 2 as for the DM Clearing contingency. If rejections are going to be handled the way CHAPS 

j=i payments are currently then we only have to provide options 3 and 4. 

hi Option 3 will cover stage statuses of 375001, 375002 and 37501 1 and allow these to go back to Repair, 

j,^ Option 4 will cover stage statuses of 375001, 375002 and 37501 1 and allow these payments to go back 

y= to the Routing module where a new payment channel will be chosen for it. 

5.%?9.3 FT4721 - French Euro Clearing. 

All French payments available from these options will be at stage-status 375??? The specifics of the 
French payments stage statuses have still to be decided. But from this screen payment types of 'SNP' 
and *TBF' will be available and depending on how FTS or the clearing themselves are going to handle 
rejections will determine which stage statuses will be picked up. 

5.2.29*4 Processing rules for options available: 



The following processes will take place for options 1,2 and 3 

a. Transaction set to 'L'ive. 

b. Tran-inactive set to space. Tran inactive upto Acknowledgement processing is 01, at 
Awaiting Batching it is 06 and at Batched it is 09. At each of these of these stages a Control total 

is kept of all the payment amounts. When a payment moves on a stage the amount is backed out from the previous 
stage's totals and added to the next. CNTTPTOOl. 
c . Blotter reversed, (as in current processing). 

d. Payment amount backed out from the Bilat balance and the Debit cap balance on FT-FLOW-CONTROL. 
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• For option 4 to send paymentsback to the Routing module 

a. CNTIPTD01 total^^fcpd out. (as above) 

b. Payment amount t^JJ out from FT-FLO W-CONTROL balances. 

c. Payment type changed to 4 CLG* as the Router will decide an appropriate channel. 

d. Tran-live set to". 

5.2.30 Test aids 

Four new test aid programs will be required to display and update the new Flow control files. Just one screen for each as 
not much data to display. As follows:- 

Display FT-FLOW-CONTROL 
Display FT-FLOW-TRANS 
Update FT-FLOW-CONTROL 
Update FT-FLOW-TRANS 

The display programs will be promoted to user test and production, whereas the updat eones will go to user test only. 
Also the FT-TRANS test aids will need to be amended to display the new fields 

5.2.31 FT4716 - Online maintenance of ECC table 



Special update routine will be generated to cater for the maintenance of these table records. The existing GPPM facility 
cannot be used because various validation rules need to be included when maintaining the table details. These are: 

1. Ensure that clearings can only be 'O'pened if FFT is a member of the clearing. 

2. For clearings that FFT is not a member of, validation should ensure that CHASE-CORRESPONDENT details 
are present. 

3. If more than one cut-off time is required, validation should ensure that the second cut-off time is not before the 
first cut-off time. 

4. CLEARING-TYPE can only be *N* for NET, 'R' for RTGS. 

5. CLEARING-STATUS con only be 'O'pen or 'Closed. 

6. CLEARING -member-capture can only be *M" for manual or 'E' for electronic. 

7. CLEARING-HOLIDAY-TABLE can only be *HOL' or 'CUR* 

V. 

i\~ The CLEARING-CON I ROLLED details will be used by the flow control module when no bilateral record is found. See 
Ms! flow control section of SDIP for more detailed discussion on the use of this data. CLEARING inforrnation information 

will need to hold details on the holiday table to use for deciding on when the clearing is on holiday and when it is not. 
ijl See appendix G for screens. 

ill 

5.232 FT4717 - Online maintenance on CMD table 



Within straight through, payment input as well as in payment routing FTS will need to check which clearings a bank is a 
member of. To cater for this, a new table is to be generated (CMD) that will allow for the maintenance of channel 
membership details by Paybank. Each Paybank/Channel combination will be held on a different record to allow for easy 
maintenance and prioritising of channels. A new module (FT4717) will be generated to create and maintain the details on 
this table. 

Data will be either manually captured or updated through the use of a batch process from existing table data. 

The table will not only hold details on the clearings to which a Paybank is linked, but will also hold details relating to the 
preferred routing method if PaybankTTheir Correspondent* is not a member of a clearing which FFT is a member of. 
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^|^Dg changes 



5.2.33 Stage status < 370' Hard 

There are some programs that havent already been mentioned that will require changes purely because they have stage 
status of 370 hard coded. These are listed below 

FT301 1 - Automatic Charge calculation. Line 261 5 — Add check for *369\ 

FT3516 - Reset Payments Release Date and Time. As we are adding new stage statuses for 'Delay Awaiting Payment 
Routing' this program has to be changed to include the stage-statuses 369001 - 369010. 
Increase array for #LOOP to process 10 instead of 9. This is because the stage stauses will increase, and 
currently it is only processing 9 stage statuses for * 3 7000*. 

FTGN3 1 1 - FTS Transaction Delay Menu. Currently checking transactions at stage status of '370*. Change to include 
*369\ 

FTUN313 - FTS Transaction Delay - Option 2 Release Transaction from Hold. 

FTUN3 14 - FTS Transaction Delay. - Option 3 Override Delay period for Transaction. 

Add new check after line 5070, if #SPLIT-STAGE = '369* update 2HOLD-STAGE = '369003* and 
#STAGE = '369\ 

FTUN2827 - ATR Payments to Release from Delay. 

Add a check to see if current stage status is *369' or '370' and update #STAGE-STATUS to either 
'369003* or 
'370003* accordingly. 

5JS34 FT4055 - Overnight update of X border 



i-i 



This will be changed to set the stage status to 373 instead of 375 for Euro transactions only. Will need to worry about the 
branch some how. 

It will set the TRAN-INACTTVE to 07, and maintain Control totals by backing out the 01 control totals and updateing 
the 07 control totals. 



Ohm* JW: C****OOW3\TEX*~0OGatT Doe 
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5.3 SUBSYSTEM PROGRAI^^EX 

5.3.1 AMENDED PROGRAMS 



NB the estimates below are for the changes required by the 5-10 Payment Routing and Flow control Euro Task. The work 
required for changes due to the other aspects of Euro are not considered here in this SDIP. 





^ KAME. : 


•LANGUAGE. . 


TITLE 


Spec 


Code 


Test / "; : ;- V 




v- ... 






Estimate 


Estimate - 


esrrrnate C ■ 




FT 1408 


Natural 


FT-TRANS enquiry test aid 


0 


1 






FT1458 


Natural 


FT-TRANS update test aid 


0 


1 








Natural 


Payment input single screen 


2 


4 


3 






Natural 


Payment input 3 screen 


2 


3 


3 




FTK0011 


Cobol 


Initial msg processing 


1 


4 


3 




FTK0014 


Cobol 


Straight thrus 


2 


4 


4 




FTK0015 


Cobol 


Straight thrus 


2 


4 


4 




FTK0017 


Cobol 


Straight thrus 


2 


4 


4 




FTTC0032 


Cobol 


Straight thrus 


2 


4 


4 




FTKO033 


Cobol 


Straight thrus 


2 


4 


4 




FTK0025 


Cobol 


Hard coded '370' changes + x border 


0.5 


0.5 


1 








CLC, MA 


1 


3 


3 




FTK0008 


Cobol 


Prod gen 


3 


4 


3 




FTK0049 


Cobol 


PC contingency 


0 


3 


2 


L J 


FTKO058 


Cobol 


Acknowledgement Processing 


o 


0.5 


1 




FT3011 


Natural 


Automatic Charge Calculation 


o 


0.5 


I 




FTGN3 1 1 


Natural 


FTS Transaction Delay Menu 


0.5 


0.5 


0.5 




FTGN313 


Natural 


Release Tm from Hold 


0.5 


0.5 


0.5 


i : i 


FTGN314 


Na rural 


Override Delay period for Trn 


0.5 


0.5 


0.5 




FTUN2827 


Natural 


ATR Pmnts to Release from Delay 


0.5 


0.5 


0.5 


"si 


FTGN934? 


Natural 


Transaction enquiry 


0 


1 


1 




FT3425 


Natural 


DM Contingency 


2 


2 


2 


Li 


FT3594 


Natural 


Accounting feed generation 


0.5 


1 


1 


vy 


FT3516 


Natural 


Reset Payments Release Date and 


0.5 


1 


1 


u 






Time 








in 


FTUN038 


Natural 


Departmental end of day 


1 


3 


1 




FT3222/7/8 


Natural 


Queue status enquiry 


1 


2 


1 




FTGN900 


Natural 


Control totals 


0 


1 


1 




FT4055 


Natural 


Overnight Batch for held X border 














TOTAL ESTIMATES 


26.5 


56.5 


49.0 



rui i ■■■i n p»» r nwiN'wt nnr» » > umii T rmi 
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5.3.2 NEW PROGRAMS 



'--.r^' .->* > •• 


• -• > " n * . *. : 

^ nv* ■■ - 

,-\JXi.. O v . 


-. TITLE .'-...* 


; Spec 
estimate.^-' 


:\:<^deV>:^ 

esriniate * 


.estimate 


FT47ftf> 

-T 1 *T / UU 


Natural 


Overnight reset of Flow Control balances 




2 


1 


f H f vl 


Natural 


Batch load of CMD table for EB A/ECU 


2 


2 


2 


FT4702 


Natural 


tfatcn load ot CMD table for German 


2 


2 


2 


FT4703 


Mil M ir^ 1 


Overnight deletion of FT-FLOW-CONTROL 


1 


2 


2 


FT4710 


"NT'ITtit-o 1 
i> ULUI al 


Start/Stop Routing and Flow Control BGD's 


0.5 


0.5 


0.5 


FT4712 


lidlLUal 


Online Flow control Program 


2 


4 


2 


FT47 1 2N* 


i>aiurai 


Online Flow control sub-programs 


2 


4 


2 


FT4715 


Natural 


Flow control static data maintenance 


2 


3 


2 


FT47 1 & 

r l *♦ / jo 


Natural 


Pay routing Static data update ECC 


2 


3 


2 


r l*f / i / 


Natural 


Pay routing Static data update CMD? 


2 


3 


2 


r i*t / is 


Natural 


New Euro (FFT) Queue Status Enquiry 


1 


3 


2 




Natural 


CrlAPS/EBA Euro Clearing Contingency 


1 


1 


2 


FTJ.77 1 


Natural 


French Clearing Contingency 


1 


1 


2 






Payment Router 


10 


10 


10 


r J rvW7 1 


v^ODOi 


tfilat Flow Controller 


7 


10 


6 


r J is.uuyz 


Cobol 


Debit Cap Flow Controller 


5 


10 


6 


r 1 ivUUy J 


Cobol 


Prod gen validation module 


3 


5 


4 


FTK0094 


Cobol 




c 


10 


5 


FT14?? 


Natural 


Display FT-FLOW-CONTROL 


0 


1 






Natural 


Display FT-FLO W-TRANS 


0 


I 






Natural 


Update FT-FLOW-CONTROL 


0 


1 






Natural 


Update FT-FLOW-TRANS 


0 


1 








TOTAL 


49 


79 


54.5 
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5.4 FILE CHANGES 

5.4.1 Changes to FT-TRANS 



New Fields : 



VField , 


Fermrt 


Description „ 


FT-CLEARING 


A9 


Indicate which channel to use (e.g.: /RTGS/ELS) 


FT-URGENT-IND 


Al 


4 Y* or 'N' 


FT-TARGET-IND 


Al 


'Y' or *N' 



5.4.2 New FT-FLOW-CONTROL database file 

All the agreed limits that the Flow Control processors will use to control payments will be stored on a new FTS database 
file called FT-FLOW-CONTROL. The limits held will be : 

1. A debit balance limit for each paybank and channel combination. This will reflect the bilateral relationships chase 
has set up with other banks. 

2. A debit balance limit for each channel. This will reflect the limit imposed on Chase by the clearing Central Bank. 
Also held on this database will be other information that will be of use to Ops. 

!"=^ The layout of the records will be :- 



Pi 









KEY-DATA 






BRANCH 


A3 


Required as there may be clearing branches other than FFT (eg J.P.Morgan) 


BILAT-ID 


All 


Identifier for the Clearing member set to XXXXXXXXXXX for debit cap recs 
NB on EAF or ELS records this field will contain the BLZ code. On any other 
channels this field will contain the swift address. 


CHANNEL 


All 


Identifier for the channel, either pay type or our correspondent swift address 








FLOW-DATA 






LIMIT 


N18.4 


Balance Limit agreed for this relationship (stored as a negative amount) 


CONTROL-IND 


Al 


Y - Bilat is controlled, N - bilat is not controlled 

Set by Ops. On Channel/XXX records this is not set, the system doesnt access it 
anyway. But instead assumes Y. 


BALANCE 


N18.4 


Current balance 


NO-HELD 


N9 


Number of payments held due to this check 


AMT-HELD 


N18.4 


Total amount of all payments held 


MAX-AMT 


N18.4 


Maximium payment amount allowed for this relationship 


BILAT-HOLD-IND 


Al 


4 Y* - hold all records for this bilat/channel, *N* - dont. 

Used by the Flow controller tasks. When a payment is held no point trying to 
release other payments for this Bilat/channel so update this flag to *Y\ At end of 
processing updates it back to not held. 








MIS-DATA 






NO-RELEASED 


N9 


No of Payments released passed this check but not acked 


AMT-RELEASED 


N18.4 


Amount of Payments released passed this check but not acked 


NO-CREDITS 


N9 


No of Confirmed Credits received 


AMT-CREDITS 


N18.4 


Amount of Confirmed Credits received 
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FT4710 needs a superdescripto r of BRANCH/CH ANNE L/R n.AT.m The Bilat Contn 
Examples of key values on req 



190GEBANL2REAF 



►t or of BR> 



190GEBANL2REBA 



190 GEBANL2 RELS 



190GEBANIj2RSNP 



190GEBANL2RTBF 



1 9 0GEBANL2 PBNK2GBL 



190 PBNK2 GBLCHE 



190 PBNK2GBLEAF 



190PBNK2GBLEBA 



190 PBNK2 GBLELS 



190PBNK2GBLSNP 



190 PBNK2 GBLTBF 



1 9 0XXXXXXXXTBF 



can also use this. 



Superdescriptors 

The Online and batch controllers requires the following superdescriptor 

BRANCH 
BILAT-ID 
CHANNEL 



5^g3 New Flow Control transaction database file - FT-FLOW-TRANS 
5ii!5. 1 Gen era! 

The Flow control system (both online and background tasks) will have to access the transaction data in various ways. 
"~ This will be provided by having a number of superdescriptors (at least two large ones). Also some new fields will be 
~ required specifically for use by Flow control. 

! ul The™ new su P ers Md fields could be added to FT-TRANS. However, it was felt that this would slow down the existing 
r= FTS functions considerably, and a new database file (along the lines of IDR-TRANS) would be preferable. This will be 
yl called FT-FLOW-TRANS. 

■sis 

63 0ne record will be created on this file every time an FT-TRANS transaction gets to the new STAGE-STATUS OF 
'AWAITING FLOW CONTROL CHECKS*. 

The records will have a status field that marks its progress through the Flow control process. It will have values of :- 

* 1 ' - Awaiting the Bilat check 
*2' - Awaiting the Debit Cap check 
* (Space) - Released to Product generation 

The Released status is set to space so that old records do not appear in the Adabas indexes and therefore slow the system 
down. 



i mm-. c«i«ceiw>Taw ntwmw ooe 
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5.4.3.2 Record layout 



The fields on this file will be :- 



PAYMENT-DATA 




Description :■ <: 


BRANCH 


A3 


Required because there may be other clearing branches as well as FFT (eg 
J.P.Morgan) 


STATUS 


Al 


As described above. Must be Null Suppressed. 


CLEARING- 
GROUP 


A3 


Used to stream the tasks. Value populated by the Router from table CLG 
Group 


HELD IND 


Al 


This will have two possible values Yes and No. If a record is held due to the 
Bilat check then its status will be 'Awaiting Bilat' and its HELD IND will be set 
to 'Y\ 


BILAT ID 


All 


The swift address of "Their correspondent" bank that we are sending the payment 
to (via clearing). I.E the Clearing member. 


CHANNEL 


A12 


The clearing mechanism chosen for this payment taken from FT-TRANS. 
PAYMENT-TYPE or for Correspondent banking use our correspondent swift 
address with K Z" in front. 


PAYMENT-TYPE 


A3 


Payment type from FT- TRANS. Needed to group correspondents into one stream 
of 'CPO'. 


URGENT IND 


Nl 


If the payment is urgent then this ind will be set to "1". Otherwise set to "2" 


AMOUNT 


P14.4 


Credit amount from FT TRANS.CRAMT 


FT-TRANS-ISN 


P8 


The ISN of the transaction record on FT-TRANS 








AUDIT-DATA 






DATE-CREATED 


P8 


This field will hold the date the record was created on this database file. For Audit 
purposes only. DDMMCCYY 


TIME-CREATED 


N6 


This Field will hold the time the record was created on this database fileJFor Audit 
purposes only. HH:MM:SS 24 hour clock. 


ACTION-ID 


A7 


Op id of user that moved this payment from flow control, or blank if there was 
no manual action. For Audit purposes only 


ACTION-TIME 


N6 


HH;MM:SS 24 hour clock. For Audit purposes only 


ACTION 


Nl 


Stored online option used 

- 1 Reroute 

- 3 Cancel 

- 5 Repair 

- 6 Release 

- 7 Released by background task 



5.4.3.3 Superdescriptors 

The Bilat Flow controller will require the following superdescriptor called *BILAT-CHECK* 

BRANCH 
STATUS 

CLEARING-GROUP 
URGENT- IND 
PAYMENT-TYPE 
BILAT-ID 
AMOUNT 

(NB in Adabas version 6 up to 20 fields are now allowed in any Superdescriptor) 
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•The Debit Cap Flow Controllerwjll require the following superdescriptor called 'DE^fcCAP-CHECK 11 



BRANCH 
STATUS 

CLEARING-GROUP 
CHANNEL 
URGENT- IND 
AMOUNT 



lleyjAll require the following superdescriptor called 'DE^&C> 

W 9 



The Online Flow Control process will require the following superdescriptors:- 









BRANCH 


BRANCH 


BRANCH 


HELD 


HELD 


HELD 


CHANNEL 


CHANNEL 


CHANNEL 


STATUS 


URGENT-TND 


BILAT-ID 




STATUS 


STATUS 




BILAT-ID 


URGENT-IND 




AMOUNT 


AMOUNT 



.4.4 Table BGD 



As well as adding new records to BGD, note that the new records will be utilising the second data line for extra critical 
times if required. Hence the table profile will need changing to include these. 

The new records below assume that on 1/1/99 we will have just two clones of each Flow controller - one for RTGS and 
one for NETS ^Correspondent banking . I.E. 6 in total. 

TABLE-ID: BGD DESC : TRANSACTION ID 

DELAY j HELD RECORD ) CRITICAL TIME START J 

CRITICAL TIME END | HELD RECORD DELAY | BKG TRAN DATA 

TABLE-DATA (FIRST 50 CHARACTERS) 

0500 0003 0000 0000 0000 NF90BABND002 ???616 Y 

0500 0003 0000 0000 0000 NF91AABND001 NET616 Y 

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 

0500 0003 0000 0000 0000 NF91BABND002 RTS616 Y 

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 

0500 0003 0000 0000 0000 NF92AABND001 NET616 Y 

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 

0500 0003 0000 0000 0000 NF92BABND002 RTS616 Y 

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 



VER 


TABLE - 


Y 


F90A 


Y 


F91A 


Y 


F91B 


Y 


F92A 


Y 


F92B 
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5.4.5 



Table CLG 



This is a new table. It allows the grouping of different clearing channels into a group that one Flow control stream will 
then process. For 1/1/99 we will have just two clones of Flow Control one for RTGS and one for net + correspndent 
banking. The clearing group values must correspond to the values entered on the BGD table for the flow control tasks. 
Therefore entries required on this table will be :- 

TABLE- ID: CLG DESC : PAYMENT TYPE 

CLEARING GROUP 

SEL VER TABLE-KEY TABLE-DATA { FIRST 50 CHARACTERS) 



Y EAF NET 

Y EBA NET 

Y ELS RTS 

Y CHE RTS 

Y SNP NET 

Y TBF RTS 

Y CPO NET 



5.4.6 CMD - Clearing channel member details and preferred routing method . 



U 1 The table details will consist of the following. 

□ 



r~ 




format 


Remarks V 


\ •» 


MEMBER-SWIFT 


All 


Swift address of paybank. 


iJJ 


CHANNEL 


A3 


Must be on the Channel table. 


y 






(Exception *TGT* and *COR' will not be added to ECC table). 




PRIORITY 


N2 


Used by the router to prioritise channels when more than one route 
available. 


: -i 


DESTINATION-CLEARING 


A3 


If the Channel information indicates that TARGET is to be used, this 


? : =f 






data will indicate the RTGS that their correspondent is a member of and 


is S 






which they wish us to use to clear through TARGET. 


*i 1 


START-DATE 


N8 


Date when paybank first becomes a member. 


'42 


END-DATE 


N8 


Date when paybank ceases to be a member. 



Key: MEMBER-SWIFT (A3) 
CHANNEL (A3) 
PRIORITY (N2) 

DESTINATION CLEARING (A3) 



DATA START-DATE 
END-DATE 



I IUT: OMMMM'SirEW-'OeOa/ DOC 
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5.4.7 Table ECC - Euro Cleari 



nnel information. 





F&rmat 


Remarks - -\. ^s-"..:S-'^-s>^ 


FTS-BRANCH 


N3 


F 1 5 branch 


CLEARING-ID 


A3 


All valid clearing channels not only those that FhT is a member 
of. 


tLtAKJINu-McMBtR 


Al 


*Y'es or *N'o 


V^LxiAKiiNLi -b 1 A I Uo 


Al 


'O'pen or "Closed (Always closed if FFT is not a member). 


r""»r c A D TXT/" 1 TVT>tT 


A4 


Net or RTGS 


Ci-bAKiNO -NAME 


A30 




CLEARING-DEFAULT-PRIORITY 


N2 


Unique per Branch 


CLEARING-CUT-OFF-TIME 


N7 


Cut-off time for normal payments. 


SETTLEMENT-CUT-OFF-TIME 


N7 


Cut-off time for setlement payments. 


MINIMUM-VOLUME 


N8 


If channel has any rninimum volume requirements 


MINIMUM-VALUE 


N12 


If channel has any rninimum value requirements 


CHASE-CORRESPONDENT 


All 


This will hold details on the correspondent that CHASE uses to 
access the clearing channel. Swift-address ? 


CLEARING -MEMBER-CAPTURE 


Al 


'M'anual, 'EMectronic. This detail will be used when maintaining 
the Members of clearing table information. See below. 


CLEARING -CONTROLLED 


Al 


*Y' - needs control, "W - no control needed. (Used by flow 
control) 


CLEARING -HOLIDAY-TABLE 


A3 


*HOL' or 'CUR' 


CLEARING -COUNTRY-CODE 


N2 


Country code where the clearing operates. 


CENTRAL-CLEARING-BANK 


A12 


This will hold details on the central clearing bank for the channel 
For TARGET payments, this will be the receiving bank 


NOSTRO-ACC-NO 


N10 | Holds the nostro account number for the clearing. 



PJ Key: FTS-BRANCH 

W CHANNEL-ID (A3) 

hi FFT-MEMBER (A I ) 

CHANNEL-STATUS(Al) 

CHANNEL-TYPE (A 1 ) 

5.4fg LCP Table - Local Clearing Payment Type. (Changes) 

Ul The LCP Local Clearing Payment Type table contains default payment type details for each of the FTS branch clearings. 
*p This default will be changed for 6 1 6 to cater for the new CLG payment type. 

TABLE- ID: LCP DESC: CLEARING PAYMENT- TYPE 

BRANCH (3) 
PAY -TYPE (3) 



SEL VER TABLE -KEY 
Y 616 



TABLE -DATA (FIRST 50 CHARACTERS) 
CLG 
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5.4,9 Table QSE 



TABLE -ID: QSE DESC : 



1 

: QUE1 



lUE STATUS 
OFFSET 
TSQNAME 



ENQUIRY 



SEL VER TABLE -KEY 



TABLE -DATA (FIRST 50 CHARACTERS ) 



Y 001 1 

Y 002 1 

Y 003 1 



F90AA3ND 
F91AABND 
F92AABND 



5.4.10 Table STF 



This table ensures Background Task Start/Stop function displays tasks in the required order. New entries are required 
for the new background tasks as follows ;- 



TABLE- ID: STF 



DESC: START/ STOP FUNCTIONS 
APPL- ID/ ORDER-NO 

TRANS - ID/DESC/ START- IND/ STOP - IND/TERM - ID (X5 ) 



VER 


TABLE - 


-KEY 


TABLE -DATA (FIRST 50 CHARACTERS ) 


Y 


FLOW 


01 


F90AFTT 


EURO 


PAYMENT ROUTER 


Y 


FLOW 


02 


F91AFFT 


EURO 


BILAT CONTROLLER 


Y 


FLOW 


03 


F91BFFT 


EURO 


BILAT CONTROLLER 


Y 


FLOW 


04 


F92AFFT 


EURO 


DEBIT CAP CONTROLLER 


Y 


FLOW 


05 


F92BFFT 


EURO 


DEBIT CAP CONTROLLER 



5/4.1 1 SST Table (Stage Status) 



TABLE-KEY TABLE-DATA 

1234 5 6789012 34557 8901234 56789 01234567 890123 45678 901234 5 67 8901234567 8 90 

369XXX 

373XXX 

374XXX 



C h i — ■ IW: CU MHpffWTCT^-OOMW OOC 
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5.4.12 TTY Table (Stage Statu 

Current entries :- 

TABLE-ID: TTY DESC :■ TRANSACTION TYPE (BRANCH CODE-PAY OR CRED TYPE) 
SEL VER TABLE-KEY TABLE-DATA (FIRST 50 CHARACTERS) 



Y 


616CHK 


CHK 


YYYY3370009370039 


Y 


Y 


616CHQ 


CHEQUE 


YY 5370003370033 




Y 


616CPO 


CPO 


YYYY43 7 0003 3 7003 3 




Y 


616DD 


DD 


YYYY3370009370039 


Y 


Y 


616DFT 


DRAFT 


YYYY4370003370033 




Y 


616EAC 


CONV 


YY 5370004370034 


YY 


Y 


616EAF 


EAF 


YY 4370004370034 


YY 


Y 


616ELS 


ELS 


YY 4370004370034 


YY 


Y 


616IAT 


I AT 


YYYY33 6 8001370 039 


Y 


Y 


616MPO 


MPO 


Y YY5370003370003 




Y 


616NMC 


NMC 


YYYY537000 337003 3 


N 



Change the following entries 
TABLE- ID: TTY DESC : TRANSACTION TYPE (BRANCH CODE-PAY OR CRED TYPE) 
U\ SEL VER TABLE-KEY TABLE-DATA (FIRST 50 CHARACTERS) 

a - 

M Y 616EAC CONV YY 5369004369034 YY 

1'* Y 616EAF EAF YY 43 6 90043 69034 YY 

FU Y 616ELS ELS YY 4369004369C34 YY 

b j and add the folowing for the new clearing channel payment types for FRENCH, EB A, CHAPS EURO as well as the 

\~ * default payment type of * CI-G * 





Y 


616CLG 


CLG 


YY 


43690113690?? 


YY 




Y 


616SNP 


SNP 


YY 


43690123690?? 


YY 




Y 


616TBF 


TBF 


YY 


43690133690?? 


YY 


iJl 


Y 


616EBA 


EBA 


YY 


43630083690?? 


YY 




Y 


616CHE 


CHE 


YY 


43690103690?? 


YY 



5.5 SYSTEM INTERFACES 



iMl CMftNDOrttt.TCMtt-OMal*? DOC 
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6. ALTERNATIVES COr^ERED 

7. SECURITY 

8. PERFORMANCE CRITERIA 

AVAILABILITY 

RESPONSE 

VOLUMES 



9. ACCEPTANCE CRITERIA 

10. BACKUP/RECOVERY 

11. CONTINGENCY 

12. HARDWARE/SOFTWARE ENVIRONMENT 
1?, PRODUCTION CONTROL 

14s GENERAL 

1|j SCHEDULING 

16? JCL CHANGES 

1£j CONVERSION PLAN 

18gj PILOT PARALLEL RUN 
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[Insert date. J 



[Insert name of addressee company. J 
[Insert address of addressee company.] 

Attn: [Insert name of appropriate individual at addressee company.] 
Re: Purchase Order Enquiry Module Chase TradeTrack 

Dear [ ]: 

[Insert name of addressee company.] ("you") currently have an agreement with [Insert name of 
appropriate Chase entity.] ("Chase**) pursuant to which Chase provides to you an electronic trade-related 
service involving letters of credit. In connection with that service, Chase collects certain information and 
stores it on its computer systems. Some of that information comprises invoice numbers, names of 
beneficiaries, purchase order numbers, letter of credit numbers and payment numbers ("Information-). 
You have advised In conjunction with the use of the electronic trade-related service, Chase that you 
would like to be able to access the Information over the Internet and Chase has agreed to provide that 
access to you, subject to the terms and conditions of this letter agreement. Those terms and conditions 
follow: 

Chase will issue a login identification number and a password. When you want to 
access the Information over the Internet, you will access the following Internet URL: [Insert the 
appropriate URL.] As of the date of this letter agreement, that URL ("POEM TradeTrack URL") is within 
the trade finance pages on the website owned and operated by The Chase Manhattan Corporation and 
some of its subsidiaries. When you access the POEM TradeTrack URL, you will see a page that contains 
a link to the Information. That link is labeled [POEM TRADETRACK]. To access the Information, click 
on that link and, when prompted to do so, enter your login identification number and your password. 
Chase may change the POEM TradeTrack URL from time to time but, if it does so it will notify you 
thereof. 

2. You shall safeguard your login identification number and your password. Chase shall not be 
liable for any use of either or both of the login identification number and the password, whether that use is 
by individuals whom you authorized to use them or by any other individuals. 

3. As of the date of this letter agreement, Chase is not imposing any separate fee or charge in 
consideration of its providing the Information to you. Chase, however, may impose or assess such a fee 
or charge, or increase any such a fee or charge then existing, at any time in the future but, in the event 
that it plans to do so, it will notify you at least [Insert appropriate number.] ( ) days in advance. 

4. Either you or Chase may terminate this letter agreement at any time by notifying the other 
thereof at least five days in advance. 

5. As of the date of this letter agreement, the Information will be stored on Chase's computers in 
Hong Kong. In the event that you access the Information from the United States (or from some other 
countries other than Hong Kong) during your regular business hours, you may do so at a time that is 
outside of the normal business hours of Chase's Hong Kong office. In addition, although Chase will 
attempt to update the Information at least once each business day, the data it uses to do so may be data 
from the previous day's transactions, so that updated Informauon at the end of any particular business day 
in Hong Kong may reflect data captured in Hong Kong as of the end of the immediately preceding 
business day. Chase therefore does not warrant the timeliness of the Information, nor does it warrant the 
accuracy of Informauon. CHASE MAKES NO WARRANTIES OF ANY KIND WITH RESPECT TO 



THE INFORMATION INCLUDING, BUT NOT LIMITED TO, ANY WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 



[Is reference to the location of the physical server that the customer is accessing required? The flow that 
will exist upon the implementation of TradeTrack is from HK server (GTS system) to a server in NY 
within the Chase.com area. The customer will be accessing the NY server, not the HK server HK server 
will replicate the data to the NY server. When this product expands in its usage, the server may be 
located at any Chase Branch. Therefore, would recommend not referring to a physical location] 

6. In no event shall Chase be liable (no matter what the cause of action) for any damages of any 
kind pursuant to, or in connection with, this letter agreement. In the event, however, that Chase begins to 
impose a separate fee or charge pursuant to section 3. of this letter agreement, beginning on the effective 
date of such fee or charge: (i) the first sentence of this section 6. shall not apply and (ii) in no event shall 
Chase be liable (no matter what the cause of action) for any damages of any kind that, in the aggregate, 
exceed in any year the amount determined by multiplying the amount of such fee or charge (or, in the ' 
event that such fee or charge is not a monthly fee or charge, the monthly equivalent of such fee or charge) 
by three. In no event shall Chase be liable (no matter what the cause of action) for any indirect, special or 
consequential damages of any kind, even in the event that it is advised of the possibility that such damages 
may arise, occur or result. 

7. No modification of this letter agreement shall be effective unless it is in a writing that is signed 
by authorized representatives of Chase and you. No waiver of any right or remedv under this letter 
agreement shall be effective unless it is in a writing that is signed by an authorized representative of the 
party to be charged therewith. 

8- This letter agreement shall be governed by, and construed and enforced in accordance with, the 

laws of the State of New York, United States of America, without giving effect to the principles of conflict 
of laws of such state. Any action, proceeding or suit brought with respect to this letter agreement shall be 
brought only in courts located in the Borough of Manhattan in such state. 



Please indicate your agreement with the terms and conditions of this letter agreement by signing 
the enclosed copy of this letter agreement on the lines provided for that purpose . Then return that 
executed copy to me. 



Very truly yours, 



[Insert name.] 
[Insert title.] 



AGREED: 

[INSERT NAME OF COMPANY.] 

By: 

Title: 

Date: 

209645:v01 
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APPENDIX K - CHANGES TO CONTROL TOTALS SCREEN. 
APPENDIX L - TRAN INACTIVE PROCESSING DIAGRAM 
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APPENDI X A - NFW PROCESSUS 



I- ? 



W FOR FTS 



3d*- -vi^*?' '• . .~ *V; ■■ ' 



1 








i;Straight 








There are instances where a 
transaction may bypass the 
risk control process. 




qpebrt/Credif 
Jp^.yalidatiqa3 



AGK^ 
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APPENDIX B - DIAGRAMS OF j VF; 
B1.0 TRANSACTIONS WITH SAP 



TUS'S 
PRODUCTS 



W 



370xxx 



Prodgen first 
read 



"370003 



MT100 



m MHS 



Swift cont for 
CHAPS 



Feeds off 
375101 -CPO 
375001 - non CPO 



All products done 
375102 -CPO 
375020 - instrument 
only 

375002 - others 
OR not all done 
375001 - (these alsogo 
back to prod gen) 



Prod gen 
second read 



Products 
still reqd 
375001 
375101 



375001 - Gateway 
closed so reformat 
(DM only) 



-Ack 



1 




batching 




-380002 



375003 



1 


r 




EOD today 



Ommmmt *tf : CttOTDOHfnrWWWEMOOr DOC 
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B2.0 TRANSACTIONS WITH S 



Y PRODUCTS 



370xxx 

I— 



Prodgen first 
read 



MT100 









i -ct 

iJJ 




5 ; =? 






Ack— 



I 

370003 Swift cont for 
I CHAPS 



Feeds off 
375101 -CPO 
375001 - non CPO 



First 
prod 
375002 



F58 



380 



Prod gen 
second read 



Products 
still reqd 
375001 
375101 



AH products done f 
375102 -CPO 
375020 - instrument 
only 

375002 - others 



375 





002 


003 


000 








r 














batching 




EOD today 




Batch job 



375 

"oo r 



375001 - Gatewjay 
closed 
so refomnat(DM only) 
or needs more 
products 
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APPENDIX r 
Screen 2; 



FLQW C OFTBQlJ^MlC DATA MAINTKNANnp Qr ?F r|vg 



FTS FLOW CONTROL MAINTENANCE HH:MM DD/MMAT 



Enter CHANNEL ID 
BILAT-ID 



PF3= BACK PF12= MENU 

FT4713M1 



Sereen 2: 



FTS FLOW CONTROL MAINTENANCE SUMMARY SCREEN 
CHANNEL ID BILAT-ID LIMIT 



XXXXXXXXXXX XXXXXXXXXX 999999999999999999.9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999.9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999.9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999.9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999^9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999.9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999.9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999^9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999.9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999*9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999 9999 
XXXXXXXXXXX XXXXXXXXXX 
XXXXXXXXXXX XXXXXXXXXX 
XXXXXXXXXXX XXXXXXXXXX 

XXXXXXXXXXX XXXXXXXXXX 

XXXXXXXXXXX XXXXXXXXXX 999999999999999999.9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999^9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999.9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999.9999 
XXXXXXXXXXX XXXXXXXXXX 999999999999999999.9999 
PF2= SELECT PF3= BACK PF7= DOWN PF8— UP PF12= MENU 



999999999999999999.9999 
999999999999999999.9999 
999999999999999999.9999 
999999999999999999 .9999 



HH:MM DD/MM/YY 

_MAXIMUM AMOUNT__ 

999999999999999999.9999 

999999999999999999.9999 

999999999999999999.9999 

999999999999999999.9999 

999999999999999999.9999 

999999999999999999.9999 

999999999999999999.9999 

999999999999999999.9999 

999999999999999999.9999 

999999999999999999.9999 
9999999999999999999999 

999999999999999999.9999 
9999999999999999999999 

999999999999999999 9999 

999999999999999999.9999 

999999999999999999.9999 

999999999999999999.9999 

999999999999999999.9999 
9999999999999999999999 

9999999999999999999999 
FT4713M2 
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FTS FLOW CONTROL MA 



ANCE DETAIL SCREEN 



HH 



CHANNEL 
BILAT-ID 
CONTROL-IND 
LIMIT 

MAXIMUM AMOUNT 
BALANCE 

NO. OF PAYMENTS HELD 
AMOUNT HELD 

NO. OF PAYMENTS RELEASED 
AMOUNT RELEASED 

NO. OF PAYMENTS ACKED 
AMOUNT ACKED 

NO. OF CONFIRMED CREDITS 
AMT OF CONFIRMED CREDITS 



/MM/YY 



xxxxxxxxxxx 
xxxxxxxxxxx 

X 

999999999999999999.9999 
999999999999999999.9999 

999999999999999999.9999 
999999999 

999999999999999999.9999 
999999999 

999999999999999999.9999 
999999999 

999999999999999999.9999 
999999999 

999999999999999999.9999 



PF2=UPD PF3= BACK PF4= NEXT PF 12- MENU 



S&ten 3: 



N&te; CONTROL-IND must not be displayed for Channel /XXXXXXXXXXX 



FT4713M3 



data 
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Mn SCREENS 



BRCH 616 DOE 2 OS FTS QUEUE STATUS ENQUIRY - DOE 205 PAYMENTS 10-56 ON 

2 AWAITING STRAIGHT THROUGH j. ACC p. ORD CHA?S INSTR ^ 

3 AWAITING BLOTTER COMPLETION 5 j Q 71 

4 AWAITING COMPLETION/RETURNED FROM VERIFY. . 7 1 4S 53 

5 AWAITING VERIFICATION 20 65 252 5 342 

6 AWAITING SIGHT VERIFICATION S 9 2 16 

7 FORWARD VALUED TRANSACTIONS \ 39 290 41 419 

8 AWAITING CLC APPROVAL 

9 AWAITING MARKETING APPROVAL 2 1 25 1 29 

10 IN IDR - AWAITING EXCESS CALCULATION 

11 IN IDR - AWAITING EXCESS APPROVAL... \ 15 3 189 l 208 

12 AWAITING GSS IDR APPROVAL 129 12g 

13 IAT'S AWAITING AUTOMATCH PROCESSING 

14 IAT'S AWAITING MANUAL MATCH PROCESSING 7S 75 

15 IN DELAY AWAITING RELEASE ; 

16 AT PAYMENT ROUTING 

17 AT FLOW CONTROL 2 

18 AT PRODUCT GENERATION 58 58 

19 PENDING REMOVAL 1 ■ 3 

QUEUE 1 SRCE (A, M) OR V/DATE BACKVAL CURR EXC CAT DOE 

PF2=DET, PF3=BACK. PF4=LIST, PF9=TOTALS, PF16=CR. QUEUE 205 

PF5=FLQW CONTROL, PF1 0-BREAKDOWN 15-18 FT4732M1 FT4732 030 



There are two new options from this screen, PF10 to go to a breakdown screen for queues 15-18 (described below) 
and PF5 to go to the Online Flow Control screens. 

The first screen will look very similar to and in fact be based on the current Queue Status Enquiry Function. 
The Product Generation Queues are summarised into one line. The At Delay queue now includes At Delay 
Awaiting Prod Gen and the new At Delay Awaiting Payment Routing (369XXX). 

J^^l^ nCW qUeUeS> 1 far P 8 *"" 11 * at Flow Contro1 (374XXX) and 1 for payments at Payment Routing 
(373XXX). The Flow Control queue is a summary of payments at Bilat Check and Debit Cap Check. 
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PF10 to go to the Breakdown screen 



BRCH S16 DOE 205 FTS QUEUE STATUS ENQUIRY - DOE 205 PAYMENTS 10:56 ON 

I.ACC P.ORD CHAPS IKSTR ALL 

1 AT DELAY AWAITING PAYMENT ROUTING 

2 AT FLOW CONTROL BILAT CHECK 

3 AT PLOW CONTROL DEBIT CAP CHECK 

4 AT DELAY AWAITING PRODUCT GENERATION 

5 AT PRODUCT GENERATION - MESSAGE DELIVERY. - 

6 AT PRODUCT GENERATION - MESSAGE ACKNOWLGMT 

7 AT PRODUCT GENERATION - WAITING SERIAL NO. 

8 AT PRODUCT GENERATION - OVERNIGHT HOLD .... 

QUEUE 1 SRCE (A, M) OR V/DATE BACKVAL CURR EXC CAT DOE 

PF2=DET , PF3=BACK, PF4 =LI ST, PF 9= TOTALS , PF12 =MENU f PF16=CR . QUEUE 205 
PF5=FLOW CONTROL FT4 732M2 FT4 732 03 0 



riThe second screen is a breakdown of queues 15-18 on the first screen and is accessed via the PF10 key from 
ijlhe first screen. It includes: 

is it 

jvAt delay awaiting Payment Routing. This is a new status 369XXX and is for payments going 
lYjthrough the new processes (Payment Routing and Flow Control). 

U\ 

TTAt Flow Control Bilat Check. Stage status of 374XXX, all payments will be within the Flow Control 
Function awaiting the bilat check or held because of the bilat check. 

!~^At Flow Control Debit Cap Check. Stage status of 374 XXX, all payments will be within Flow Control 
j function awaiting the Debit Cap check or held because of debit cap check. 

~ Kt Delay awaiting Product Generation. This is a current queue status, will be all payments at 370XXX. 

U At Product Generation - The next four queues are for payments at various stages of Product Generation 
and currently exist on Queue Status Enquiry. 

PF5 to go to Online Flow Control 

Pressing PF5 will take users to the Online Flow Control screens. Should be able to toggle between 
these screens and the Queue Status Enquiry functions (from either screen). 
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APPENDIX F- CONTINGENCY SC 

F1.0 German Clearing. 



BRCH 616 DOE 205 FTS PAYMENTS DM CONTINGENCY PROCESSING 15:4S ON 20Nov97 



TOTAL NUMBER OF DM PRODUCTS REJECTED BY THE LZB : 0 



ROUTE ALL REJECTED PAYMENTS FOR REPROCESSING 
ROUTE INDIVIDUAL REJECTED PAYMENT FOR REPROCESSING 
ROUTE OTHER COMPLETED PAYMENT FOR REPROCESSING 
ROUTE INDIVIDUAL PAYMENT TO PAYMENT ROUTER 
ENTER OPTION : 

ENTER TRN : (OPTIONS 2,3 AND 4 ONLY) 



PF2=ACK PF3=BACK PF9=REFRESH TOTALS 12=MENU 



FT3415M1 FT3425 005 



F2f0 CHAPS Euro Clearing. 



BRCH 671 DOE 205 FTS PAYMENTS CHE/EBA CONTINGENCY PROCESSING 15:45 ON 20NOV97 
TOTAL NUMBER OF CHE/EBA PRODUCTS REJECT AT CLEARING: 0 

1. ROUTE ALL REJECTED PAYMENTS FOR REPROCESSING 

2. ROUTE INDIVIDUAL REJECTED PAYMENT FOR REPROCESSING 

3. ROUTE OTHER COMPLETED PAYMENT FOR REPROCESSING 

4. ROUTE INDIVIDUAL PAYMENT TO PAYMENT ROUTER 
ENTER OPTION : 

ENTER TRN : (OPTIONS 2,3 AND 4 ONLY) 



PF2=ACK PF3eBACK PF9 -REFRESH TOTALS 12=MENU 

FT4 7I3M1 FT4713 
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\ 

F3.0 French Euro Clearing. 



BRCH 671 DOE 20 5 FTS PAYMENTS FRENCH CONTINGENCY PROCESSING 15:4 5 ON 20Nov97 
TOTAL NUMBER OF FRENCH PRODUCTS REJECTED BY CLEARING: 0 

1. ROUTE ALL REJECTED PAYMENTS FOR REPROCESSING 

2. ROUTE INDIVIDUAL REJECTED PAYMENT FOR REPROCESSING 

3. ROUTE OTHER COMPLETED PAYMENT FOR REPROCESSING 

4. ROUTE INDIVIDUAL PAYMENT TO PAYMENT ROUTER 
ENTER OPTION : 

ENTER TRN : (OPTIONS 2.3 AND 4 ONLY) 



PF2=ACK PF3=BACK P F 9 * RE FRESH TOTALS 12=MENU 



FT4714M1 FT4714 00S 
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APPENDIX G -ECC ST ATT P D,\T^^| M \ I S U < | SCREENS 

GhO Screen 1: Enter CLEARING ID and mode of table access 



oKt-H : 6 71 DOE: 205 


EURO CLEARING CHANNEL INPUT 


11:30 ON 06DEC97 


PLEASE ENTER 


CLEARING ID XXX 






OPTION _ (A) DD 






(M)ODIFY 




PF3=BACK, PF12=MENU 










FT4174M1 



G2.0 Screen 2:Display table details (maintenance option), enter table details (add option) 



BRCK: 671 DOE: 205 


EURO CLEARING 


CHANNEL INPUT 


11 :31 ON 06DEC97 


CLEARING ID 


XXX 


NAME XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 


CLEARING STATUS 


X 


CLEARING TYPE 


xxxx 






CLEARING MEMBER CAPTURE 


X 






CLEARING CONTROLLED 


X 


FRANKFURT MEMBER 


X 


CHASE CORRESPONDENT 


AAAAAAAAAAAA 


CUT OFF TIME 


NNNNNNN 


MINIMUM VOLUME 


NNNNNNNN 


SETTLEMENT CUT OFF 


NNNNNNN 


MINIMUM VALUE 


NNNMNNNNNMNN 


CHANNEL HOLIDAY TABLE 


XXX 


CENTRAL CLEARING BANK 


AAAAAAAAAAAA 


CLEARING COUNTRY CODE 


XXX 


NOSTRO ACCOUNT NUMBER 


NNNNNNNNNN 


ENTER- VALIDATE , PF3*BACK, 


PF12=MENU 












FT4 714M2 



I M: C.WWOOMSirWUmfK» DOC 
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APPENDIX H - CIVTD STATIC DA 



TENA^CT 



BRCH : NNN 



DOE: WWW 



TABLES -FTS RECORD ENQUIRY 



09:44 ON 20NOV97 



TABLE- ID: CMD DESO. MEMBER | CLEARING ( PRIORITY ] DESTINATION- CLEARING 
START DATE ! END DATE 



+ + LAST CHANGED BY 

TABLE -KEY MASK : CCCCCCCCCCCCCCNNCCC 

EXISTING DATA: DUETDEFF ELS 01 USER ZMT0000 DATE 99999999 TIME 999999 

USER DATE 0 TIME 0 



PENDING DATA: 



+ 1 + 2. 

TABLE-DATA MASK1 : NNNNNNNNNNNNNNNN 
EXISTING DATA1: 1998010119991231 
PENDING DATA1 : 



TABLE -DATA MASK2 
EXISTING DATA2 
PENDING DATA2 



PF3*BACK, PF12=MENU 



FTM21591 FTG2159 003 



BRCH: NNN 



DOE: NNN 



TABLES -FTS RECORD ENQUIRY 



09:55 ON 20NOV97 



TABLE-ID: CMD DESC : TRANSACTION ID 

START DATE j END DATE 



SEL VER TABLE -KEY 



TABLE-DATA (FIRST 50 CHARACTERS) 





Y 


DUETDEFF 


ELS 01 


1998010119991231 




Y 


DUETDEFF 


EAF02 


1998010529991231 




y 


DUETDEFF 


SNP03 


199901012999123 




Y 


DUIBAEAD 


TGTC1PTE 


1999010129991231 


*= i 


Y 


EEFIITR1 


TBFOl 


1999010129991231 




Y 


EEFIITR1 


SNP02 


1999010119991231 


fi5 


Y 


EEFIITR1 


EBA03 


1999010119991231/ 

199901011999123*1 


Y 
Y 


PACAPHM1 


COR01PTE 



Preferred routing method data. TARGET to be 
used with their correspondent receiving through 
PTE clearing. 



Preferred routing method data. Correspondent to 
be used to access the PTE clearing. 



PF2=SELECT, PF3*EXIT, PF5=RESTART, PF12=MENU, ENTER= DISPLAY NEXT SCREEN 



I M: C»MNOOM«1TrwU#>PEMOcrOCIC 
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APPENPTX J - Continued 
12.0 Main Summary Screen 

FTS PAYMENT CHANNEL ENQUIRY/ CONTROL HH : MM DD /MM/ YY 

Page 1 







HELD BI-LATS 


HELD DEBIT CAP 


NBR 


CHANNEL 




NBR 


AMOUNT ( 0 0 0 * S ) 


N3R 


AMOUNT (000, S) 


URGENT 


EAF 




999999 


9 999 999 QQQ 


99999 9 


a qqq aaa oqq 


999 


ELS 




999999 


9, 999, 999, 999 


999999 


9, 999. 999, 999 


999 


SNP 




999999 


9, 999, 999, 999 


999999 


9,999,999, 999 


999 


TBF 




999999 


9, 999, 999, 999 


999999 


9. 999, 999, 999 


999 


EBA 




999999 


9,999, 999, 999 


999999 


9, 999, 999, 999 


999 


CHE 




999999 


9,999, 999, 999 


999999 


9, 999, 999, 999 


999 


CORRESP 


001 


999999 


9, 999, 999, 999 


999999 


9 , 999, 999, 999 


999 


CORRESP 


002 


999999 


9. 999,999, 999 


999999 


9, 999, 999, 999 


999 


CORRESP 


003 


999999 


9. 999, 999, 999 


999999 


9, 999, 999, 999 


999 


CORRESP 


004 


999999 


9,999,999,999 


999999 


9,999,999,999 


999 


CORRESP 


oos 


999999 


9, 999, 999, 999 


999999 


9, 999, 999, 999 


999 


CORRESP 


006 


999999 


9,999,999, 999 


999999 


9, 999,999, 999 


999 


CORRESP 


007 


999999 


9,999,999,999 


999999 


9, 999,999, 999 


999 


CORRESP 


008 


999999 


9, 999,999, 999 


999999 


9, 999. 999, 999 


999 


CORRESP 


009 


999999 


9, 999, 999, 999 


999999 


9, 999,999,999 


999 



Enter to view options, PF3 Exit, PFS Restart 

PF7 Page Back, PF8 Page Forward, PF9 Qu eue Status Enquiry, PF12 Main Menu 

From this screen you can 

1. Enter *?* to display options available. 

2. PF5 to Restart from the top. 

3. PF9 to toggle to Queue Status Enquiry. 

4. PF8 to page down through other channels/correspondents. 

5. PF7 to page back through channels/correspondents. 

6. PF12 Main Menu 



i'lj On entering to view options available the following window will be displayed. 
\y\ Options 

P=j 1 - Reroute Channel 

2 - Display all Urgent Payments by Status 

3 - Display all Paybanks by Channel 

Enter Option :X 
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13.0 Option 2 - Urgent Payment^fChannel 



This option will access the records by Superdescriptor 2 (section 5.2.3.3.) and display all urgent payments for the 
chosen channel in order of Status (either *B* or 4 D') then paybank then value i.e. the lowest value first The time 
displayed will be the time elapsed since the payment first entered Flow Control. The screen will be refreshed each 
time ENTER is pressed.From this screen you can 

1 . Enter a '?" to display the different options available for each payment. 

2. Enter a Status either 'B* for Bi-lats or *D* for Debit Cap and PF4 to see 
the Non-urgent payments. (See later section) 

3. Enter the required option.(See later section ) 

4. PF5 to restan from the top. 

5. PF8 to page forward through the urgent payments. 

6. PF7 to page back. 

7. PF9 Queue Status Enquiry. 

8. PF3 to go back to Main Channel Summary Screen. 

9. PF 12 Main Menu. 



FTS PAYMENT CHANNEL ENQUIRY /CONTROL HH : MM DD/MM/YY 

CHANNEL XXXXXXXXXXX SUMMARY SCREEN - URGENT Page 1 

NET BALANCE FOR XXXXXXXXXXX IS 999.999,999,999.99 



STATUS TRANS. REF PAY BANK AMOUNT TIKE 



B 


01234567 


XXXXXXXXXXX 


1, 000, 000 


00 


00 


02 


00 


B 


88834S67 


XXXXXXXXXXX 


7,367,439 


00 


00 


:05 


31 


B 


9999G667 


XXXXXXXXXXX 


534,222.456 


00 


00 


07 


45 


B 


23987653 


XXXXXXXXXXX 


725.765,776 


00 


00 


07 


57 


B 


84849S93 


XXXXXXXXXXX 


750. 543, 098 


00 


00 


05 


03 


B 


S5434376 


XXXXXXXXXXX 


850,773, 452 


00 


00 


03 


21 


D 


01234567 


XXXXXXXXXXX 


98, 543, 09S 


00 


00 


.10 


09 


D 


88834557 


XXXXXXXXXXX 


121, 765, 776 


00 


00 


30 


32 


D 


99996S67 


XXXXXXXXXXX 


323,222,456 


00 


00 


14 


03 


D 


239876S3 


XXXXXXXXXXX 


424 ,367, 439 


00 


00 


15 


40 


D 


84849593 


XXXXXXXXXXX 


777, 999. 999 


00 


00 


03 


59 



Enter *?' to display Options, PF4 for Non-urgent X, PF9 Queue Status Enq, 
PF7 Page Back, PF8 Page Forward, PF3 Exit, PFS Restart, PF12 Main Menu 
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14. 0 Option 3 - Display all Pay for Channel 



When selected this option will display for each paybank, the number of transactions and the amounts for each status i.e 
Held Bilat and Held Debit Cap. It will also provide the functionality to be able to toggle left and right to see Bilat and 
Debit Cap excess positions and limits. This will allow the user to guage how much the Bilat and Debit Cap positions 
will go to if the Held bilats are released. From either of these screens you can 



I. 

2. 
3. 
4. 
5. 
6. 
7. 
8. 
9. 



Enter a '?* to display the different options available for each 
payment. 

PF10/PF11 to toggle right or left to see Excess Positions and back. 
Enter required option against any paybank. 
PF5 to restart from the top. 

PF8 to page forward through the urgent payments. 
PF7 to page back. 

PF3 to go back to Main Channel Summary Screen. 
PF 12 Main Menu. 



CHANNEL./ PAYBANK SUMMARY SCREEN 
CHANNEL: XXXXXXXXXXX 

NET BALANCE IS 3,999,999,999,999.00 



HH : MM DD/MM/YY 





HELD 


BI- 


LATS 




HELD 


DEBIT CAP 




NBR 


PAYBANK 


NBR 




AMOUNT 




NBR 


AMOUNT 




URGENT 


PAYEANK1 


99999 


9, 


999, 999, 999, 999 


.00 


99999 


9, 


999, 999, 999, 999 


.00 


999 


PAYBANK2 


99999 


9, 


999, 999, 999, 999 


.00 


99999 


9, 


999, 999, 999, 999 


.00 


999 


PAYBANK3 


99999 


9, 


999, 999, 999, 999 


.00 


99999 


9, 


999, 999, 999, 999 


00 


999 


FAYBANK4 


99999 


9, 


999, 999, 999, 999 


00 


99999 


9, 


999, 999. 999, 999 


.00 


999 


PAYBANK5 


99999 


9, 


999, 999, 999, 999 


00 


99999 


9, 


999,999. 999, 999 


.00 


999 


PAYBANK & 


99999 


9, 


999, 999, 999, 999 


00 


99999 


9, 


999, 999, 999, 999 


00 


999 


PAYBANK7 


99999 


9, 


999, 999, 999, 999 


00 


99999 


9, 


999, 999, 999, 999 


00 


999 


PAYBANK8 


99999 


9, 


999,999,999,999 


00 


99999 


9. 


999, 999, 999 , 999 


00 


999 


PAVBANK9 


99999 


9, 


999, 999. 999,999 


00 


99999 


9, 


999, 999, 999, 999 


oo 


999 


PAYBANK10 


99999 


9, 


999, 999, 999, 999. 


00 


99999 


9, 


999, 999, 999, 999 


00 


999 


PAYBANK11 


99999 


9, 


999,999.999,999. 


00 


99999 


9, 


999, 999, 999, 999 


00 


999 



Enter ■?' to view options, PF3 Back, PF5 Restart PF7 Page Back, Status :X 
PF8 Page Forward, PF9 Queue Status Enquiry, PF11 Right, PF12 Main Menu 



CHANNEL / PAYBANK SUMMARY SCREEN 
CHANNEL: XXXXXXXXXXX 

NET BALANCE IS 9,999,999,999,999.00 



HH -.MM DD/MM/YY 



(AMOUNTS SHOWN IN MILLIONS) 





BILAT 


BILAT 


DEBIT CAP 


DEBIT 


CAP 


PAYBANK 


EXCESS POSN 


LIMIT 


EXCESS POSN 


LIMIT 




PAYBANK1 


9, 


999, 999 


9, 


999, 999 


9, 


999, 999 


9, 


999 


999 


PAYBANK2 


9, 


999, 999 


9, 


999, 999 


9, 


999, 999 


9, 


999 


999 


PAY3ANK3 


9, 


999, 999 


9, 


999, 999 


9, 


999, 999 


9, 


999 


999 


PAYBANK4 


9, 


999,999 


9, 


999,999 


9, 


999, 999 


9, 


999 


999 


PAYBANK5 


9, 


999,999 


9, 


999,999 


9, 


999, 999 


9, 


999, 


999 


PAYBANK6 


9, 


999,999 


9, 


999, 999 


9, 


999, 999 


9, 


999, 


999 


PAYBANK 7 


9, 


999, 999 


9. 


999, 999 


9, 


999, 999 


9, 


999, 


999 


PAYBANK 8 


9, 


999,999 


9, 


999, 999 


9, 


999, 999 


9, 


999, 


999 


PAYBANK 9 


9, 


999,999 


9, 


999,999 


9, 


999, 999 


9, 


999, 


999 


PAYBANK10 


9, 


999, 999 


9, 


999, 999 


9, 


999, 999 


9, 


999, 


999 


PAYBANK11 


9, 


999, 999 


9, 


999. 999 


9, 


999, 999 


9, 


999, 


999 


PAYBANK12 


9, 


999,999 


9, 


999,999 


9, 


999, 999 


9. 


999, 


999 



Enter •?• to view options, PF3 Back, ?FS Restart PF7 Page Back, Status:X 
PF8 Page Forward, PF9 Queue Status Enquiry, PF10 Left, PF12 Main Menu 
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15.0 Non-Urgent Payments for Chosen Channel. 



This screen displays non-urgent payments for a channel and status and is displayed in order of amount 
(smallest first). It is accessed from the Urgent Payments for Channel screen. The access key to retain these 
records is Superdescriptor 2 (section 5.2.33) with the urgent- ind set to space. 



FTS PAYMENT CHANNEL ENQUIRY/ CONTROL HH.-MM DD/MM/YY 

CHANNEL XXXXXXXXXXX SUMMARY SCREEN - NON URGENT Page 1 
STATUS: HELD AT BILAT 

NET BALANCE FOR XXXXXXXXXXX 999,999,999.999.99 



TRANS REF 


PAY BANK 


AMOUNT 




TIME 




0123456 


XXXXXXXXXXX 


1, 998, 787 


00 


00 


.02 


.00 


8883456 


XXXXXXXXXXX 


7, 999, 988 


00 


00 


OS 


31 


9999666 


XXXXXXXXXXX 


57, 999, 960 


00 


00 


07 


45 


2398765 


XXXXXXXXXXX 


72,898,450 


00 


00 


07 


-57 


8484959 


XXXXXXXXXXX 


595,453,321 


00 


00 


05 


03 


5S43437 


XXXXXXXXXXX 


725, 773, 452 


00 


00 


03 


21 


0123456 


XXXXXXXXXXX 


750, 543, 098 


00 


00 


10 


09 


6883456 


XXXXXXXXXXX 


8S0, 765, 776 


00 


00 


30 


32 


9999666 


XXXXXXXXXXX 


876,222,4S6 


00 


00 


14 


03 


2398765 


XXXXXXXXXXX 


998, 367, 439 


00 


00 


15 


40 


8484959 


XXXXXXXXXXX 


999, 999, 999 


00 


00 


03 


59 



Uk Enter »?' to display Options. 

|,> PF4 Urgent, PF7 Page Back, PF8 Page Forwa rd, PF3 Back, PF12 Main Menu 

VI \ 

w 
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APPENDIX J. - STNGI ~ — 1^ T 

A3 . Possible positioning of URGEN T^TTARGET INDICATORS. 



BRCH 616 DCS 870 FTS M/PAYMZNT SWIFT INPUT - DETAIL ENTRY 10:47 ON 30M*y97 

TRN * BLOT REFi 000330 CURRi 183 VALUE DATE ■ PRE ADVt 
BRCH: 616 MESSi INTERNAL i PAY TYPE: AMOUNT: 

DB fcCCl CUST REFi IEfST TYPE t 



BAN* CODE 



TP-CAB-REQ, 
AUTO-CHGi 
BULK- IND. 



REQ-BYx NO-CCNF. 
CHARGE P/L TYPE AMT 



CLR 
MAME 

PF3-Back P PS. Tog PFfi-aem PP9«Pvd PF9-Chg PFIO-Enq PP12-Knu" 

FT3415N2 FT3415 001 



T20 . 
T32A t 
SRN t 

No message available 



Original Message 

Priority 



FF23-Prev PF24>Next 



Page 



Current Map Layout. 



BRCH 615 DOE S73 



XXXXXXXJOCXXXX -XX 
IKST TYPE ; XX 



PTS M/PAYKEST SWIFT ISfPUT - DETAIL ENTRY 10*47 OK 30XayS7 
TRN. XXXXXZX BLOT REFt XXXXXX CURS. XXX VALUE DATE : XXXXXX PRE ADV: X 
BRCH: XXX HESS * XXX INTERNAL i X PAY TYPE: XXX AMOLT^t 
Da ACC. XXXXXXXXXXXX XXXXXXXXXX CUST REFi 
^tXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXX 
U SUOCXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
! 3COOCXXXXXXXXXXXXXXXXXXXXXXXX.XXXXXXX 

^-=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

_J :i 3COOC<XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 



XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
XXXXXXXXXXXXXXXXX>OCXXXXXXXXXXXXXXXX 



XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 



*XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

^ Sao^^aoa^^x^x^^^xx^oa^aSSi 

I^ r ^3CXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

UjCXXXXXXXXXXXXXXXXX XX XXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

C XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

AWB J ,= *XX>QaoCXXXXXXXXXXXXXXX>aXXXXXXXXXXXX TP-CAB-REQ, X REQ-BYi XXX NO - CON? « X 
.. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX AUTO-CHCi X CHARGE P/L TYPE AMT 
CLR XXXXXXXXXX BANK CODE XXXXXX BULK- IND i X 1 X XX XXXXX .XX 

PE ^"? aCk PFS-Tog PF6-Rem PF8 - Fv^'p^^Chg 3 '^^ ^ % XXXXX 

FT341SX2 FT3415 0O1 



original Message 
T20 : XXXXXXXXXXXXXXXX Priority XX 
T32A: XXXXXX XXX XXXXXXXXXXXXXXX 
SRK i XXXXXXXXXXXXXXXXXXXX 
XX.XXXXXXXXXXXXXXXXXXXXX>OQCOCXXXOOCX>3000e 



XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 



XXXXXXJCOOCXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 



PP23-Prev PP24-Next 



Potable positioning of Urgent Indicator. 



BRCJ U£ 16 D0E "0 PTS M/PAYMEKT SWIFT IKPVT - DETAIL ENTRY 10,47 ON 30rUy97 
TRW. XXXXXXX BLOT REF, XXXXXX CURRt XXX VALUE DATE i XXXXXX PRE ADV. X 
BRCH j XXX KESSx XXX INTERNAL, X PAY TYPE t XXX AMOUNT, 
DB ACC. XXXXXXXXXXXX XXXXXXXXXX CUST REF: 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 



XXXXXXXXXXXXX -XX 
XXXXXXXXXXXXXXX INST TYPE. XX 



xxxxxxx>acxxxxxxxxxxxx>aexxxxxxxxxxxx 
xxxxxxxxxxxxxiocxxxxxxxxxxxxxxxxxxxx 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 



xxxxxxxxxxxxxxjocxxxxxxxxxxxxxxxxxxx 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

Jooaaoacxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

>a»ooax3axxx5ocTOoara xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

TP-CA8-REg= X RXQ-BY; XXX NO-CONF. X 
XX AUTO-CHGi X CHARGE P/L TYPE AMT 
TOO. X BULX-3ND, X 1 X XX XXXXX.XX 

— „ ^ Ipcxxxxxxxxxxxxxxxxx 2 X XX XXXXX.XX 

PFJJ-Back PFS-Tog PPg-Rem PFB.Fvd P?9^hg PF10-2nq ?F12.Mnu TGTi X 

PT341SM2 FTjklS 001 



XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 



AWB 



CLR XXXXXXXXXX BANK CODE XXXXXX 
NAME 



Original Message 
T20 > XXXXXXXXXXXXXXXX Priority XX 
T33As XXXXXX XXX 
SRN - XXXXXXXXXXXXXXXXXXXX 



XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 



XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 



XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 



XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 



P723*?rev PF 2 4. Next 



Possible Positioning for TARGET Indicator. 



Possible Positioning for Urgent Indicator. 
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A ppendix K * changes to contr 



Is screen. 



!J1 
u3 



BRCH NNN DOE NNN FTS MANUAL PAYMENTS - TODAYS CONTROL TOTALS 08:47 ON 3 0DEC97 



INPUT TOTALS 


COUNT 




AMOUNT 




BROUGHT FORWARD FROM PREV DAYS 


12395 


552, 


101, 019, 289 


.9200 


RECEIVED VIA T'SLIP/RPI INSTRUCTIONS. 


2 




25, 033 


.1500 


RECEIVED VIA SWIFT (INCLUDES FTPC) . . 


1193 


52 , 


857, 904, 510 


.3500 




269 


33, 


999, 830,751 


.4000 


RECEIVED VIA MULTICASH 


13 




96,944,710 


.2600 


RECEIVED FROM OTHER CHASE SYSTEMS .... 


314 


276,766,177,775 


.0600 


MANUALLY INPUT 


264 


27, 


782, 850,917 


.0600 



TOTAL 



14450 



943 , 604 , 752 , 987 .2 000 



TRANSACTION TOTALS 
CURRENTLY ACTIVE . . . 
AT PAYMENT ROUTING. 
AT PRODUCT GENERATION. 
REMOVED/ CANCELLED . 
AWAITING BATCHING. 
BATCHED 



PF3=BACK, PF6=CCAP PF7 



7585 556, 332, 839, 998 .33 00 
NNNN NNN, NNN, NNN, NNN. NNNN 
54 89 48 , 963,489,474 .6000 

4 9 27, 077,766,63 8 .5500 

1327 311, 23 0, 656, 875 .72 00 

0 .0000 



FTPC 



TOTAL . . . . 
PF12=MENU 



14450 



943 , 604,752,987.2 000 

FTGM9001 FTGN900 001 



L New Control Total data for At Payment Routing (contol total 07 - CNTIPTD07) 
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APPENDIX L - TRAN INACTIVE PI 
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